1.2, Аноним (2), 11:39, 03/12/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –12 +/– |
Грош цена таким разрабам, которые непроверенные внешние данные пихают в regexp
| |
|
2.3, КО (?), 11:47, 03/12/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если regexp заменить на "переменные окружения", то будет еще логичнее, а то проверка 32Tb ухе сама может вызвать кучу приятных эмоций.
| |
|
3.33, Аноним (-), 07:49, 06/12/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Все верно, но там смысл другой.
читайте внимательно
> когда непроверенные данные непосредственно внутри regexp-выражения, а не при проверке при помощи regexp
> а не при проверке при помощи regexp
Анон дочитал и был прав, а толпа бестолочей заминусовала анона.
#неидизатолпой
| |
|
2.21, Аноним (21), 17:55, 03/12/2018 [^] [^^] [^^^] [ответить]
| +/– |
Так проблема же не в regexp как таковом, а в конкретной реализации regcomp.c
PS Никоим образом не пропагандирую переписать на Хрусте.
| |
|
1.6, Аноним (6), 12:36, 03/12/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А родительский процесс не сдохнет, когда будет устанавливать такую переменную перед запуском перла?
| |
|
2.12, Аноним84701 (ok), 14:53, 03/12/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А родительский процесс не сдохнет, когда будет устанавливать такую переменную перед запуском перла?
Если я правильно понял 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
и пересобрать ядро.
| |
|
1.8, Аноним (8), 13:59, 03/12/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> regcomp.c
> могут привести к переполнению буфера
> regcomp.c
> .c
Совпадение? Не думаю. Впрочем, ничего нового.
| |
|
2.14, Акакжев (?), 15:09, 03/12/2018 [^] [^^] [^^^] [ответить]
| +/– |
Целочисленное переполнение проще всего проверить на ассемблере. Переписывайте.
| |
|
1.25, трурль (?), 01:37, 04/12/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
* Daemon потыкал палочкой в wd
<wd> яя
<Daemon> а чиво станет с перлом, если в хеш загнать 2 гига данных и заставить перл его сортировать?
<wd> будет сортировать
<ghoulWork> неожиданно
https://bash.im/quote/394858
| |
|
2.28, КГБ СССР (?), 12:09, 04/12/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Сегодня запустил vim с 1.8ГБ текста. Всё зависло на*й. Минут 30 ждал
> пока завершится vim.
Вот что бывает, когда не хочется изучать grep, awk, sed.
В суперкомпьютере Cray T3D ( ru.wikipedia.org/wiki/Cray_T3D ) процессоры работали на частоте 150 МГц (мега-, а не гига-), а всей памяти в машине было как в типичном десктопе продвинутой современной веб-макаки. Подумай над этим, анон.
| |
2.35, нах (?), 13:01, 10/12/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
сегодня в хз какой раз запустил вимя с 2.счемтотам gb текста (mysqldump без улучшизмов) которым тестирую сторадж под mysql'ем.
Ну да, оно довольно долго его жует (особенность vim и его recover), но ни разу не 30 минут.
| |
|
|
2.30, КГБ СССР (?), 13:15, 04/12/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем мне grep, awk и sed если я знаю Perl?
Зачем открывать текстовым редактором два гига текста? Что ты хотел там вычитать в этих двух гигах?
| |
|
|
|
3.37, Michael Shigorin (ok), 13:38, 10/12/2018 [^] [^^] [^^^] [ответить]
| +/– |
> на perl4 сидите? netch@ бы одобрил, да.
Dear Netch какое-то время вполне себе одобрял, пока не майданулся (надо отдать ему должное, на это ушло месяца два хорового убеждения в том, что чёрное -- это белое). Но perl вполне себе 5.26.2.
| |
|
|
|