LINUX.ORG.RU

saahriktu был прав

Эдик же.

Zhbert ★★★★★
()

Красота. С каждым годом дырки веселее.

wandrien ★★★
()

вариация на supply chain attack

Неинтересно.

intelfx ★★★★★
()

для Ъ: с помощью Юникода в код можно впихивать дырки которые фиг заметишь!

Надеюсь, через эмодзи?

Zhbert ★★★★★
()

Ух, неприятно. Глядишь, какой-нибудь юморист прочитавший эту новость возьмёт, да решит побаловаться этой дыркой.

Irben ★★★
()

Знакомые программисты на Дельфи обсуждали подобный прикол году в 2018-м. Или когда Дельфи стало полностью юникодным. Если я правильно понял, в следующей версии что-то запретили, и подобное стало невозможным.

А за несколько лет до того по той же причине предупреждали не копипастить команды в sudo bash со Stack Overflow.

question4 ★★★★★
()

Проблема не в юникоде, а в том, что компиляторы принимают на вход что-то шире множества отображаемых символов из первых 127.

t184256 ★★★★★
()

которые фиг заметишь!

В Visual Studio показываются нормализированные исходники.

То есть там ты заметишь, так как явно будет видно что закоментировано и прочее.

Например про символы 0 длины показывается warning:

identifier contains Unicode character <U+200B> that is invisible in some environments

Но код компилируется, так как код остается валидным.

fsb4000 ★★★★★
()

С опеннета:

Метод основан на применении в комментариях к коду специальных Unicode-символов, меняющих порядок отображения двунаправленного текста. При помощи подобных управляющих символов одни части текста могут выводиться слева-направо, а другие справа-налево. В повседневной практике подобные управляющие символы могут применяться, например, для вставки в файл с кодом строк на иврите или арабском языке. Но если комбинировать строки с разным направлением текста в одной строке, при помощи указанных символов отрывки текста, отображаемые справа-налево могут перекрыть уже имеющийся обычный текст, отображаемый слева-направо.

В процессе рецензирования кода разработчик столкнётся с визуальным порядком вывода символов и увидит в современном текстовом редакторе, web-интерфейсе или IDE не вызывающий подозрения комментарий, но компилятор и интерпретатор будет использовать логический порядок символов и обработает вредоносную вставку как есть, не обращая внимание на двунаправленный текст в комментарии.

Вообще, конечно, и смех, и грех. Наверное, ситуацию, когда одни видимые символы могут перекрывать другие, надо считать некорректной. И в редакторах кода, по крайней мере, надо предусмотреть режим, в котором такие строки выделяются красным цветом для привлечения внимания. Думаю, это не очень сложно.

Также по прочтении стало интересно, а как же поступают для добропорядочной вставки строк на иврите в код? Сначала добавляют энное количество пробелов с расчётом на будущий текст, а потом пишут сам текст?

P.S. Вот именно по схожей причине мне не нравится синтаксис питона. Там, конечно, не Trojan Source, максимум — логика программы сломается. Но сама идея зависимости работы программы от невидимых символов — плохая.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Также по прочтении стало интересно, а как же поступают для добропорядочной вставки строк на иврите в код? Сначала добавляют энное количество пробелов с расчётом на будущий текст, а потом пишут сам текст?

Проблема не в этом. По-моему, они там криво всё объяснили.

Расскажу, как сам думаю.

В памяти все данные идут «от начала к концу» во всех языках. Вот только визуальное положение положение «начала» и «конца» у разных языков разное. Вот что получается:

Допустим, у нас есть последовательность байт: «abcde ABCDE xyz». При этом заглавные буквы в этом примере означают какие-то буквы иврита.

Движок видит, что начало абзаца идёт в направлении LTR. Он начинает выстраивать глифы по порядку: «abcde».

Потом он встречает «A» и понимает, что нужно переключиться на RTL. Она заглядывает дальше и смотрит, сколько их там: «ABCDE». Кончились.

Теперь он рассчитывает глифы. Получает визуально слово: «EDCBA».

Добавляет его к уже построенной строке глифов: «abcde EDCBA».

Дальше идёт переключение на LTR.

В результате получается: «abcde EDCBA xyz».

Это правильный результат рендеринга. Никакого бага — последовательность символов на экране не соответствует порядку в файле. Так и задумано!


А теперь — проблема. Используя коды принудительной смены направления, можно в наши «ABCDE» из примера загнать самые разные символы, а не только буквы иврита!

Вот и получится что визуально кусок текста будет, например, закомментирован. А на самом деле — нет!

wandrien ★★★
()
Последнее исправление: wandrien (всего исправлений: 3)
Ответ на: комментарий от hobbit

Ну и вот тут смотри еще: https://www.w3.org/International/articles/inline-bidi-markup/uba-basics

Существует направление фрагмента и существует более общее направление в рамках абзаца/строки.

Это позволяет атакующему разбить строку на фрагменты и визуально переупорядочить их так, чтобы «закомментированный» текст оказался раскоментированным и наоборот.

Даже примеры из статьи на w3.org по сути уже готовая атака, просто никому ранее в голову не приходило подставить туда нужные символы.

wandrien ★★★
()
Последнее исправление: wandrien (всего исправлений: 2)

Предлагаю везде заменять ; на ;

rupert ★★★★★
()
Ответ на: комментарий от t184256

Так ладно бы если компиляторы... Твоя софтина сама примет скорее всего и далеко не всегда всё будет гладко и без дырок.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

И пока я это не пихаю в eval, это полбеды.

t184256 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.