Pull to refresh

Comments 7

Интересно, как измерялась «значимость» и «масштабность» этого переполнения буфера по сравнению с другими. Чем эта выявленная дыра масштабнее других переполнений(выявленных и невыявленных)?
То было во первых — ИМХО (извиняюсь, если не понятно).

Ну и хоть «значимость» и «масштабность» невыявленных дыр я оценивать не возьмусь :)
про конкретно эту — ну я, на вскидку, с десяток проектов могу назвать, где оно актуально (и я не про дериваты сейчас), ибо для некоторых сам воспроизводил магеллан на ура с «предсказуемымо» повторяющимся результатом, для других как минимум могу представить примерный сценарий для вектора «атаки».

Готового эксплойта я по понятным причинам тут не дам… (пусть скрипт-киддис сами ищут)… Но если уметь читать исходники и взглянуть на тесты в фиксе, то многое становится понятнее при оценке «значимости». Про «масштабность» же — думаю и так должно быть понятно (например, вы слово WebSQL в тексте заметили? и с какого года оно было невыявлено?).
По мне так выявленная дыра она или есть или её нет. То есть это бинарное состояние. Значимость — это уже исключительно приписываемое свойство, а не объективное.
Во первых, важна не столько сама ошибка, сколько возможность использовать ее как средство «атаки», сложность создания эксплойта на предмет например «remote code execution» и иже с ним, повторяемость (или стабильность) этого вектора в живой системе, и собственно (если про масштабность) — распространенность функционала в контексте возможного применения ошибки.
Во вторых, не каждая ошибка — есть сразу «дыра». О чем собственно и речь выше.
Сравниваются переполнения буфера. И почему-то одно переполнение буфера является более масштабным и значимым. Зря я в эту дискуссию влез, только карму себе порчу. Объяснить что именно делает одну ошибку переполнения буфера в том же самом приложении более масштабным чем другое переполнение буфера иначе как демагогией на тему того, что она более масштабная потому что она более масштабная, и «другая» здесь не могут, так что наверное и не стоило задавать. Просто было интересно как такое может быть, на примере.
Просто было интересно как такое может быть, на примере.

Ну вот вам пример:


char buf[5];
sprintf(buf, "%0100d", x);
...

тоже делает переполнение буфера, но:


  • понятно что на стеке, но возможно не очень (или не всегда) понятно, где конкретно (применимость потенциального инжекта может быть очень непрозрачна);
  • переполнение всегда постоянной длинны (100+1-5), т.е. нельзя этим "снаружи" управлять (например sprintf(buf, "%0*d", len, x); уже несколько вкуснее, но опять не факт если влияние на len "снаружи" сильно ограничено или зависит от множества параметров);
  • сильно зависит от того, что имеем после вызова (т.е. что там собственно под ...);
  • не вполне прозрачно, как конкретно это можно юзать напрямую, в контексте живой системы, если функция пользуется почем зря и/или "плавает" в стеке (или например значения x ограничены алгоритмом сверху);
  • переписывается что-нибудь очень нужное (без вариантов, например как здесь padding нулями до переменного значения x);
  • проблема окружения: если контекст спорадический (не регулярно или повторяемо), не всегда возможно влиять на это с изнанки, чтобы заставить что-то вообще (ну или в нужное время/в нужном месте) исполнить этот кусок кода;
  • или например высока вероятность что приложение поймает исключение (упадет в любом случае, но собственно remote code для RCE так и не удастся инжектировать);
  • прочие сложности и ограничения типа DEP (исполнять напрямую из стека нельзя), ASLR без возможности "вкусно" обойти, и т.д. (применимость инжекта может быть очень ограничена).

Ну и все в совокупности не делает из этой ошибки сразу же "дыру", даже потенциальную, даже в контексте оного единственного приложения (я уж не говорю про собственно реализацию эксплойта, тем более для "множества" приложений).


Magellan же — совсем не такой. Если все еще не понятно — просто поверьте.

Ну продолжайте разрешать браузерам выполнять скрипты на любых произвольных сайтах…
Only those users with full accounts are able to leave comments. Log in, please.

Articles