Сформирован (https://www.nntp.perl.org/group/perl.perl5.porters/2018/11/m...) корректирующий выпуск интерпретатора языка программирования Perl 5.28.1, в котором устранена опасная
уязвимость (https://rt.perl.org/Public/Bug/Display.html?id=133204) (CVE-2018-18311 (https://security-tracker.debian.org/tracker/CVE-2018-18311)). Проблема позволяет инициировать целочисленное переполнение, которое в дальнейшем приводит к переполнению буфера, при присвоении переменной окружения очень большого значения (более 4 Гигабайт).

Уязвимости подвержены приложения на языке Perl, которые выставляют переменные окружения через хэш %ENV с использованием в них значений на основе передаваемых пользователем данных. Проблема вызвана переполнением 32-разрялдного счётчика размера строки в функции Perl_my_setenv.

Кроме того, в обновлении Perl 5.28.1 устранены три уязвимости в обработчике регулярных выражений (regcomp.c), которые могут привести к переполнению буфера: CVE-2018-18312 (https://security-tracker.debian.org/tracker/CVE-2018-18312) (reg_node (https://rt.perl.org/Public/Bug/Display.html?id=133423)), CVE-2018-18313 (https://security-tracker.debian.org/tracker/CVE-2018-18313) (S_grok_bslash_N (https://rt.perl.org/Public/Bug/Display.html?id=133192)) и CVE-2018-18314 (https://security-tracker.debian.org/tracker/CVE-2018-18314) (S_regatom (https://rt.perl.org/Public/Bug/Display.html?id=131649)). Уязвимости могут использоваться для атаки на приложения, в которых при построении регулярных выражений (непосредственно внутри regex) используются непроверенные внешние данные.

URL: https://www.nntp.perl.org/group/perl.perl5.porters/2018/11/m...
Новость: https://www.opennet.dev/opennews/art.shtml?num=49702

• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 11:39 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,КО, 11:47 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,evkogan, 14:51 , 03-Дек-18
    • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 07:49 , 06-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 14:58 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 17:55 , 03-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Нанобот, 12:24 , 03-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 12:36 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним84701, 14:53 , 03-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 13:59 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,ананим.orig, 14:42 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Акакжев, 15:09 , 03-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,InuYasha, 14:04 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Sw00p aka Jerom, 22:52 , 03-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,cutlass, 04:47 , 04-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,iZEN, 18:50 , 03-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,трурль, 01:37 , 04-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Денис Александрович, 10:41 , 04-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,КГБ СССР, 12:09 , 04-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,нах, 13:01 , 10-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Денис Александрович, 12:15 , 04-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,КГБ СССР, 13:15 , 04-Дек-18
    • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Денис Александрович, 09:39 , 05-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Аноним, 09:54 , 05-Дек-18
• Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Michael Shigorin, 21:09 , 07-Дек-18
  • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,нах, 13:02 , 10-Дек-18
    • Уязвимости в интерпретаторе Perl, связанные с обработкой пер...,Michael Shigorin, 13:38 , 10-Дек-18

Грош цена таким разрабам, которые непроверенные внешние данные пихают в regexp

Если regexp заменить на "переменные окружения", то будет еще логичнее, а то проверка 32Tb ухе сама может вызвать кучу приятных эмоций.

Как раз через регэкспы их и проверяют зачастую.

Все верно, но там смысл другой.

читайте внимательно

> когда непроверенные данные непосредственно внутри regexp-выражения, а не при проверке при помощи regexp
> а не при проверке при помощи regexp

Анон дочитал и был прав, а толпа бестолочей заминусовала анона.

#неидизатолпой

Это один из немногих способов снять с них taint

Так проблема же не в regexp как таковом, а в конкретной реализации regcomp.c

PS Никоим образом не пропагандирую переписать на Хрусте.

по таким мелочам можно было и не клепать новость

А родительский процесс не сдохнет, когда будет устанавливать такую переменную перед запуском перла?

> А родительский процесс не сдохнет, когда будет устанавливать такую переменную перед запуском перла?

Если я правильно понял man execve

applications are guaranteed to have at
       least as much argument and environment space as was provided by Linux
       2.6.23 and earlier.  (This guarantee was not provided in Linux 2.6.23
       and 2.6.24.)  Additionally, the limit per string is 32 pages (the
       kernel constant MAX_ARG_STRLEN), and the maximum number of strings is
       0x7FFFFFFF.

то для появления уязвимости нужно всего лишь подправить константу:

/*
 * These are the maximum length and maximum number of strings passed to the
 * execve() system call.  MAX_ARG_STRLEN is essentially random but serves to
 * prevent the kernel from being unduly impacted by misaddressed pointers.
 * MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer.
 */
#define MAX_ARG_STRLEN (PAGE_SIZE * 32)
#define MAX_ARG_STRINGS 0x7FFFFFFF

и пересобрать ядро.

> regcomp.c
> могут привести к переполнению буфера
> regcomp.c
> .c

Совпадение? Не думаю. Впрочем, ничего нового.

> Аноним
> Аноним

!

Целочисленное переполнение проще всего проверить на ассемблере. Переписывайте.

Мне одно не понятно - как в регэкспах не может быть проблем в принципе =)

Если не понятно, почитай Брауэра - Теория конечных автоматов.

У инуяши хорошо получается только мечом махать

Дык
DEFAULT_VERSIONS= perl5=5.26

* Daemon потыкал палочкой в wd
<wd> яя
<Daemon> а чиво станет с перлом, если в хеш загнать 2 гига данных и заставить перл его сортировать?
<wd> будет сортировать
<ghoulWork> неожиданно

https://bash.im/quote/394858

Сегодня запустил vim с 1.8ГБ текста. Всё зависло на*й. Минут 30 ждал пока завершится vim.

> Сегодня запустил vim с 1.8ГБ текста. Всё зависло на*й. Минут 30 ждал
> пока завершится vim.

Вот что бывает, когда не хочется изучать grep, awk, sed.

В суперкомпьютере Cray T3D ( ru.wikipedia.org/wiki/Cray_T3D ) процессоры работали на частоте 150 МГц (мега-, а не гига-), а всей памяти в машине было как в типичном десктопе продвинутой современной веб-макаки. Подумай над этим, анон.

сегодня в хз какой раз запустил вимя с 2.счемтотам gb текста (mysqldump без улучшизмов)  которым тестирую сторадж под mysql'ем.
Ну да, оно довольно долго его жует (особенность vim и его recover), но ни разу не 30 минут.

Зачем мне grep, awk и sed если я знаю Perl?

> Зачем мне grep, awk и sed если я знаю Perl?

Зачем открывать текстовым редактором два гига текста? Что ты хотел там вычитать в этих двух гигах?

Надо было понять почему женщина в красном не может войти в систему

У меня проги тоже логи в редакторе смотрят;)

Как же мудр наш майнтейнер perl, не спешащий тянуть в репозиторий 5.xx.0...

на perl4 сидите? netch@ бы одобрил, да.

> на perl4 сидите? netch@ бы одобрил, да.

Dear Netch какое-то время вполне себе одобрял, пока не майданулся (надо отдать ему должное, на это ушло месяца два хорового убеждения в том, что чёрное -- это белое).  Но perl вполне себе 5.26.2.