Comments 7
Интересно, как измерялась «значимость» и «масштабность» этого переполнения буфера по сравнению с другими. Чем эта выявленная дыра масштабнее других переполнений(выявленных и невыявленных)?
0
То было во первых — ИМХО (извиняюсь, если не понятно).
Ну и хоть «значимость» и «масштабность» невыявленных дыр я оценивать не возьмусь :)
про конкретно эту — ну я, на вскидку, с десяток проектов могу назвать, где оно актуально (и я не про дериваты сейчас), ибо для некоторых сам воспроизводил магеллан на ура с «предсказуемымо» повторяющимся результатом, для других как минимум могу представить примерный сценарий для вектора «атаки».
Готового эксплойта я по понятным причинам тут не дам… (пусть скрипт-киддис сами ищут)… Но если уметь читать исходники и взглянуть на тесты в фиксе, то многое становится понятнее при оценке «значимости». Про «масштабность» же — думаю и так должно быть понятно (например, вы слово WebSQL в тексте заметили? и с какого года оно было невыявлено?).
Ну и хоть «значимость» и «масштабность» невыявленных дыр я оценивать не возьмусь :)
про конкретно эту — ну я, на вскидку, с десяток проектов могу назвать, где оно актуально (и я не про дериваты сейчас), ибо для некоторых сам воспроизводил магеллан на ура с «предсказуемымо» повторяющимся результатом, для других как минимум могу представить примерный сценарий для вектора «атаки».
Готового эксплойта я по понятным причинам тут не дам… (пусть скрипт-киддис сами ищут)… Но если уметь читать исходники и взглянуть на тесты в фиксе, то многое становится понятнее при оценке «значимости». Про «масштабность» же — думаю и так должно быть понятно (например, вы слово WebSQL в тексте заметили? и с какого года оно было невыявлено?).
0
По мне так выявленная дыра она или есть или её нет. То есть это бинарное состояние. Значимость — это уже исключительно приписываемое свойство, а не объективное.
-2
Во первых, важна не столько сама ошибка, сколько возможность использовать ее как средство «атаки», сложность создания эксплойта на предмет например «remote code execution» и иже с ним, повторяемость (или стабильность) этого вектора в живой системе, и собственно (если про масштабность) — распространенность функционала в контексте возможного применения ошибки.
Во вторых, не каждая ошибка — есть сразу «дыра». О чем собственно и речь выше.
Во вторых, не каждая ошибка — есть сразу «дыра». О чем собственно и речь выше.
+1
Сравниваются переполнения буфера. И почему-то одно переполнение буфера является более масштабным и значимым. Зря я в эту дискуссию влез, только карму себе порчу. Объяснить что именно делает одну ошибку переполнения буфера в том же самом приложении более масштабным чем другое переполнение буфера иначе как демагогией на тему того, что она более масштабная потому что она более масштабная, и «другая» здесь не могут, так что наверное и не стоило задавать. Просто было интересно как такое может быть, на примере.
0
Просто было интересно как такое может быть, на примере.
Ну вот вам пример:
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 же — совсем не такой. Если все еще не понятно — просто поверьте.
+1
Ну продолжайте разрешать браузерам выполнять скрипты на любых произвольных сайтах…
-2
Only those users with full accounts are able to leave comments. Log in, please.
Магелланова ошибка: Buffer overrun или кругосветная экспедиция средствами SQLite FTS