Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Переполнение буфера в функции glob  из состава Glibc"	+/–
Сообщение от opennews (ok) on 22-Окт-17, 02:24
В системной библиотеке  GNU C Library (glibc) выявлена (http://seclists.org/oss-sec/2017/q4/119) уязвимость (CVE-2017-15670 (https://security-tracker.debian.org/tracker/CVE-2017-15670)), которая может потенциально привести к выполнению кода злоумышленника при выполнения поиска имен файлов по шаблону при помощи функции glob(). Проблема проявляется (https://sourceware.org/bugzilla/show_bug.cgi?id=22320) при использование флага GLOB_TILDE (расширение GNU) в процессе обработки домашних директорий при помощи оператора "~", идущего после длинной строки (при обработке пути вида "~длинная_строка/a/b"). Проблема присутствует  во всех версиях Glibc и исправлена (https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c369d66e...) в находящейся в разработке ветке 2.27. Обновления для дистрибутивов пока не доступны, проследить за появлением исправлений можно на следующих страницах: Debian (https://security-tracker.debian.org/tracker/CVE-2017-15670), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-15670), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1504807), SUSE (https://www.suse.com/support/update/), openSUSE (https://lists.opensuse.org/opensuse-security-announce/2017-10/), Ubuntu (https://usn.ubuntu.com/usn/). URL: http://seclists.org/oss-sec/2017/q4/119 Новость: http://www.opennet.me/opennews/art.shtml?num=47428
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Переполнение буфера в функции glob из состава Glibc"	+2 +/–
Сообщение от saahriktu (ok) on 22-Окт-17, 02:24
Патч для glibc 2.26: https://github.com/saahriktu/saahriktu-patchesandbugfixes/bl... .
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Zenitur (ok) on 22-Окт-17, 07:24
	А есть для 2.17?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от 0x0 on 22-Окт-17, 10:49
	Для 2.17 патч не нужен.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Zenitur (ok) on 22-Окт-17, 10:57
	"Проблема присутствует во всех версиях Glibc"
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от 0x0 on 22-Окт-17, 11:02
	> ...и исправлена в находящейся в разработке ветке 2.27
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	47. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 25-Окт-17, 19:25
	2.17 != 2.27 ;)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	12. "Переполнение буфера в функции glob из состава Glibc"	+1 +/–
	Сообщение от 0x0 on 22-Окт-17, 11:05
	> "Проблема присутствует во всех версиях Glibc" Sorry! :)) Для .17 нужен -- в репозиториях своего дистра исправление подождать лучше, наверное.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	17. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 22-Окт-17, 11:52
	а для 2.4 будет?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	19. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от 0x0 on 22-Окт-17, 11:59
	Да, будет и, скорее всего, ещё много-много раз :))
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	13. "Переполнение буфера в функции glob из состава Glibc"	+1 +/–
	Сообщение от saahriktu (ok) on 22-Окт-17, 11:12
	Да, есть. https://github.com/saahriktu/saahriktu-patchesandbugfixes/bl...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	23. "Переполнение буфера в функции glob из состава Glibc"	–4 +/–
	Сообщение от Аноним (??) on 22-Окт-17, 18:37
	Сишный код такой сишный. Любители dst++ = ++ptr = src++ должны страдать. Жаль, что и остальным приходится за компанию.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	26. "Переполнение буфера в функции glob из состава Glibc"	–2 +/–
	Сообщение от Аноним (??) on 22-Окт-17, 19:40
	остальные могут взять свои остальные языки и написать на них свое ядро/ос/библиотеку/etc.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Переполнение буфера в функции glob из состава Glibc"	+2 +/–
	Сообщение от fidaj (ok) on 23-Окт-17, 15:59
	https://www.redox-os.org/ так и сделали.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	34. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от dq0s4y71 (ok) on 23-Окт-17, 16:31
	Очередная игрушечная ОС? At this time, Redox supports:     All x86_64 CPUs.     Graphics cards with VBE support (all nvidia, intel, and amd cards from the past decade have this).     AHCI disks.     E1000 or RTL8168 network cards.     Mouse and keyboard with PS/2 emulation.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "Переполнение буфера в функции glob из состава Glibc"	+1 +/–
	Сообщение от Andrey Mitrofanov on 23-Окт-17, 17:14
	> Очередная игрушечная ОС? > At this time, Redox supports: >     All x86_64 CPUs. >     Graphics cards with VBE support (all nvidia, intel, > and amd cards from the past decade have this). >     AHCI disks. >     E1000 or RTL8168 network cards. >     Mouse and keyboard with PS/2 emulation. У терминалки Торвальдса тоже было примерно так с железом поначалу. И это ничего не значит. А вот лицензию RMS подающему надежы юноше подогнал -- огонь. Не чета этим.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	48. "Переполнение буфера в функции glob из состава Glibc"	+1 +/–
	Сообщение от Аноним (??) on 25-Окт-17, 19:29
	> https://www.redox-os.org/ > так и сделали. Так и пользуйся наздоровье. Очередной ответ на все проблемы человечества, уже 42-й по счету после Minix-а.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	28. "Переполнение буфера в функции glob из состава Glibc"	+1 +/–
	Сообщение от pavlinux (ok) on 22-Окт-17, 21:36
	> Сишный код такой сишный. > Любители dst++ = ++ptr = src++ должны страдать. dst++ &= &!++ptr++ = &!src++ От такого у тя должно порвать пукан.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	29. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 22-Окт-17, 23:19
	Код как код, префиксный и постфиксный инкременты. Во всех нормальных языках так можно. Причем тут C...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Переполнение буфера в функции glob из состава Glibc"	–2 +/–
	Сообщение от пох on 24-Окт-17, 15:15
	> Код как код, префиксный и постфиксный инкременты. Во всех нормальных языках так можно. а вот смысл?  *p++ - это особенность архитектуры PDP11, где оно транслировалось в одну команду (причем *++p - в две ;-) и для тех древних процессоров это давало ну охренительный выигрыш в производительности (если *p - word, разумеется). сегодня в этом нет ни малейшего смысла. Ни в адресной арифметике, ни в обычной (если даже бы и был - оптимизатор вполне способен сам разобраться). А код становится невозможно ни прочитать, ни понять.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	43. "Переполнение буфера в функции glob из состава Glibc"	+2 +/–
	Сообщение от Аноним (??) on 24-Окт-17, 22:01
	> А код становится невозможно ни прочитать, ни понять Идите уже в дворники, вас там ждут.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	49. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 25-Окт-17, 19:33
	> а вот смысл?  *p++ - это особенность архитектуры PDP11, где оно > транслировалось в одну команду (причем *++p - в две ;-) Оно и на современных процах так же зачастую. > сегодня в этом нет ни малейшего смысла. Ни в адресной арифметике, ни > в обычной (если даже бы и был - оптимизатор вполне способен > сам разобраться). А гугл почему-то наворачивает в своем кодеке ассемблерные вставки до сих пор. С разницами в 30 раз иногда. Видимо, оптимизатор не всегда хорошо разбирается. Даже на чистом си.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	35. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от dq0s4y71 (ok) on 23-Окт-17, 16:37
	> Любители dst++ = ++ptr = src++ должны страдать. Нет по ссылке такого кода, врать-то зачем? Не хватало "- 1", такую ошибку можно на любом ЯП сделать, даже на самом "наибезопаснейшем".
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	41. "Переполнение буфера в функции glob из состава Glibc"	–1 +/–
	Сообщение от пох on 24-Окт-17, 15:39
	> Нет по ссылке такого кода, врать-то зачем? Не хватало "- 1", такую > ошибку можно на любом ЯП сделать, даже на самом "наибезопаснейшем". нет ножек - нет варенья. Если язык не умеет работать с адресной арифметикой и произвольными блоками памяти (тыщи их) - выехать за границу массива в нем не получится. Правда, и написать системную библиотеку тоже.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	50. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 25-Окт-17, 19:42
	Но тогда и писать шустрые программы не получится. Вместо перекидывания указателей будете как миленькие копировать все 20 мегабайтов там и тут.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	56. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 26-Окт-17, 19:53
	> Но тогда и писать шустрые программы не получится. Вместо перекидывания указателей будете > как миленькие копировать все 20 мегабайтов там и тут. Ну да, ну да. "pass by reference/value" нигде (тем более, даже в базиках) не было! О copy/move семантиках тоже никто нигде более слыхом не слыхивал! Откуда вы только такие лезете ...
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	57. "Переполнение буфера в функции glob из состава Glibc"	–2 +/–
	Сообщение от Аноним (??) on 26-Окт-17, 20:12
	> Ну да, ну да. "pass by reference/value" нигде (тем более, даже в > базиках) не было! Pass by reference не позволит быстро флипнуть пару 20-меговых буферов, например. Адресной арифметикой это делается, а референсом - нет. Потому что если так будет можно, это превратится в ... адресную арифметику!!! > О copy/move семантиках тоже никто нигде более слыхом > не слыхивал! Откуда вы только такие лезете ... Проблема в том что все эти мегакостыли с турбонаддувом все-равно зарубают половину эффективных оптимизаций, вызывают море side effects засирающих програмерам мозг, а как только начинает хоть немного хотеться скорости, все эти семантики вместе с васиками идут именно туда где им самое место. Да, на яве или дотнете можно написать сервер. Но фронтэндом на нагруженный сайт почему-то все сишный нжинкс и т.п. предпочитают. Такая же хрень с кодеками, алгоритмами сжатия, системными библиотеками и проч, там тормозняк вклинит вообще все программы в системе. Насколько всем нужны тормозные системы можно посмотреть на примере рыночных успехов микроядер.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	59. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от Аноним (??) on 26-Окт-17, 23:19
	>> Ну да, ну да. "pass by reference/value" нигде (тем более, даже в >> базиках) не было! > Pass by reference не позволит быстро флипнуть пару 20-меговых буферов, например. Адресной > арифметикой это делается, а референсом - нет. Потому что если так > будет можно, это превратится в ... адресную арифметику!!! Яснопонятно.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	55. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от dq0s4y71 (ok) on 26-Окт-17, 17:46
	Я имел ввиду, забыть написать "- 1" можно в любом языке. И это будет ошибкой даже в "безопасном" языке.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	7. "Переполнение буфера в функции glob из состава Glibc"	+/–
	Сообщение от 0x0 on 22-Окт-17, 10:08
	Для F27 исправление готово, но пока не добавлено в тестовый репозиторий: https://koji.fedoraproject.org/koji/buildinfo?buildID=987290
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

25. "Переполнение буфера в функции glob  из состава Glibc"	+/–
Сообщение от Аноноим on 22-Окт-17, 19:38
Дебиан жжет напалмом. > [stretch] - glibc <no-dsa> (Minor issue) > [jessie] - glibc <no-dsa> (Minor issue) Not a bug © L.Poettering
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Аноним (??) on 22-Окт-17, 23:21
	Леня же из клана красных колпаков, а не дебянов. p.s. It's not a bug.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	39. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Аноним (??) on 23-Окт-17, 23:54
	> Леня же из клана красных колпаков, а не дебянов. На самом деле, все линуксовые разработчики состоят в заговоре. А кто не в заговоре, тот разве что альт линукс разработать может.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	31. "Переполнение буфера в функции glob  из состава Glibc"	+1 +/–
	Сообщение от Аноним (??) on 23-Окт-17, 13:10
	Так там перезапись одного байта за пределом буфера нулём. Из этого в худшем случае DoS можно соорудить, и то не факт.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	38. "Переполнение буфера в функции glob  из состава Glibc"	–2 +/–
	Сообщение от Аноним (??) on 23-Окт-17, 23:53
	Ну, у леньки тоже мега-проблема была - инит демонов от рута запускал, видите ли. А от кого инит демонов должен запускать? А вони было, как будто он домой звонит и шеллкод запускает. Люблю настоящих экспертов.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Аноним84701 (ok) on 24-Окт-17, 16:14
	> Ну, у леньки тоже мега-проблема была - инит демонов от рута запускал, видите ли. А от кого инит демонов должен запускать? От указанного в настройках пользователя? А если указанный пользователь есть в системе (например, потому что не все забивают на POSIX и пользователя [0-9]+[A-Za-z]+ вполне можно добавить штатными средствами) , но комба^W инит считает его невалидным, то ... возможно, НЕ стоит запускать демона автоматом от рута? Ваш КО > А вони было, как будто он домой звонит и шеллкод запускает. Т.е. если у вас DM будет давать некоторым пользователям с невалидным ником доступ в качестве рута, то это будет в порядке вещей? > Люблю настоящих экспертов. Нарциссизм -- серьезное расстройство.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	61. "Переполнение буфера в функции glob  из состава Glibc"	–1 +/–
	Сообщение от Аноним (??) on 29-Окт-17, 18:24
	> От указанного в настройках пользователя? А в sysvinit есть способ указать пользователя в настройках? Раз уж мы про иниты. > А если указанный пользователь есть в системе (например, потому что не все забивают на POSIX и пользователя [0-9]+[A-Za-z]+ вполне можно добавить штатными средствами) , но комба^W инит считает его невалидным, то ... возможно, НЕ стоит запускать демона автоматом от рута? Чтобы выстрелить себе в ногу, нужно взять пистолет, зарядить, снять с предохранителя, направить себе в ногу и нажать спуск. Не слишком ли "специфичная" последовательность действий для "уязвимости"? > Т.е. если у вас DM будет давать некоторым пользователям с невалидным ником доступ в качестве рута, то это будет в порядке вещей? Неа. К DM имеет доступ любой, кто добрался до компа. К конфигам инита - только рут.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	63. "Переполнение буфера в функции glob  из состава Glibc"	+1 +/–
	Сообщение от Аноним84701 (ok) on 29-Окт-17, 19:44
	>> От указанного в настройках пользователя? > А в sysvinit есть способ указать пользователя в настройках? Раз уж мы  про иниты. Нет, что вы! О том же "daemon(ize) -u" приходилось только мечтать, вплоть до явления народу Рыжего Пророка! Именно поэтому "запуск от другого пользователя" — это экслюзивнейший экслюзив от мастера эксклюзивов и всякие накладки  по определению не могут считаться багами, потому что экслюзивный гладиолус! В общем, какая-то неуклюжая попытка съезда с темы. >> А если указанный пользователь есть в системе (например, потому что не все забивают на POSIX и пользователя [0-9]+[A-Za-z]+ вполне можно добавить штатными средствами) , но комба^W инит считает его невалидным, то ... возможно, НЕ стоит запускать демона автоматом от рута? > Чтобы выстрелить себе в ногу, нужно взять пистолет, зарядить, снять с предохранителя, > направить себе в ногу и нажать спуск. Не слишком ли "специфичная"  последовательность действий для "уязвимости"? Примета опеннета: "Чем левее и бредовее аналогия, тем меньше есть что сказать по теме". Для тех, кто видимо не особо разобрался в деталях, но мнение (или потребность защитить кумира) имеет: https://github.com/systemd/systemd/issues/6237 > poettering commented on Jun 29 > Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note > that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user > names. > poettering added the not-a-bug label on Jun 29 https://lwn.net/Articles/727490/ > But others thought that focusing on username validity was misplaced. > Whether or not 0day is accepted by systemd as a valid username, many found it hard > to see why the service should be started running as root when an invalid username is encountered. Т.е. мы имеем "маргинальщину" типа убунты и всякие POSIXы, где по невежеству (или из-за засилья еретиков) не слышали о Новых Откровениях и в которых такой пользователь вполне себе "valid". А еще мы имеем отличную (от остальных) логику обработки ошибок, типа "не знаешь, под каким пользователем запускать комманду - запускай от рута, не ошибешься!". И только фанаты  упорно и бодро твердят свою мантру о "нотабаг!1! От кого еще инит демонов должен запускать, как не от рута?"
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	45. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Аноним (??) on 25-Окт-17, 14:51
	Что тебе не так? Никто, в отличие от Лёни, не говорит, что это не баг. Баг, но далеко не самый страшный.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	62. "Переполнение буфера в функции glob  из состава Glibc"	–1 +/–
	Сообщение от Аноним (??) on 29-Окт-17, 18:25
	> Что тебе не так? Никто, в отличие от Лёни, не говорит, что > это не баг. Баг, но далеко не самый страшный. Пользователь Аноним84701 выше пытается доказать, что эта мега-супер-дыра всех времен и народов :-)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

37. "Переполнение буфера в функции glob  из состава Glibc"	+/–
Сообщение от Ordu (ok) on 23-Окт-17, 18:42
Надо переписать glibc на rust.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	44. "Переполнение буфера в функции glob  из состава Glibc"	–1 +/–
	Сообщение от Аноним (??) on 25-Окт-17, 02:09
	Ага, на C# еще скажи.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	46. "Переполнение буфера в функции glob  из состава Glibc"	+1 +/–
	Сообщение от Ordu (ok) on 25-Окт-17, 16:31
	> Ага, на C# еще скажи. Не. Про C# сам говори, если считаешь нужным.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	51. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Аноним (??) on 25-Окт-17, 21:39
	> Надо переписать glibc на rust. Тогда он не будет glibc. А у rust и так есть своя стандартная библиотека.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	52. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Ordu (ok) on 25-Окт-17, 22:56
	>> Надо переписать glibc на rust. > Тогда он не будет glibc. Да, название придётся сменить. Есть даже очевидный вариант: rlibc. > А у rust и так есть своя стандартная библиотека. Стандартная библиотека rust совершенно не подходит для использования её из C. Да и не выставишь её наружу через C'шный ABI.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	53. "Переполнение буфера в функции glob  из состава Glibc"	–1 +/–
	Сообщение от Аноним (??) on 25-Окт-17, 23:51
	> Да, название придётся сменить. Есть даже очевидный вариант: rlibc. Нахрен сишникам либа на Rust? > Стандартная библиотека rust совершенно не подходит для использования её из C. Либа которая сишным компилером даже не соберется ужасно необходима сишниакм. И это ты еще не видел сколько лет glibc и gcc оптимизировали, чтобы получить максимальную скорость. А так есть всякие musl и uclibc, там кода в разы меньше и уязвимостей тоже. Но меньше и фич и скорость работы, чудес не бывает. А кипа кода будет забагованой на любом ЯП. Вообще, верить что ЯП магически исправит все проблемы - бреда кусок. Во, полюбуйся, https://habrahabr.ru/post/338880/ - очень дельно пишут. Представляешь, вебари массово переполняют буфера даже когда им доступ в память вроде бы уж зарубили.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	54. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Ordu (ok) on 26-Окт-17, 03:01
	>> Да, название придётся сменить. Есть даже очевидный вариант: rlibc. > Нахрен сишникам либа на Rust? Какая им разница, на чём написана библиотека? >> Стандартная библиотека rust совершенно не подходит для использования её из C. > Либа которая сишным компилером даже не соберется ужасно необходима сишниакм. Ой, да ладно. Откуда ты знаешь? Ты уже предлагал им такую и они отказались? Поделись опытом, мне очень интересна их аргументация. > И это ты еще не видел сколько лет glibc и gcc оптимизировали, чтобы > получить максимальную скорость. Ну и отлично. Теперь можно, заглядывая в код glibc, не исследовать возможности оптимизации заново, а просто повторить то, что уже сделано, но без переполнений буферов, без целочисленных переполнений, и без прочего гумна, которое отловить в C невозможно даже статическим анализатором. Выставляя наружу C'шное API, конечно же, придётся иметь баги в своём коде: тот же sprintf, например, небезопасен по задумке своей, и поэтому придётся осознанно писать на rust'е код, который может переполнить буфер, используя для этого unsafe. Но в libc предостаточно кода, который может переполнить буфер не потому, что стандарт к этому принуждает, а просто так, по фану, и вот от этого фана libc вполне можно избавить. > Вообще, верить что ЯП магически исправит все проблемы - бреда кусок. Бреда кусок -- это... блестяще побеждать в битве с соломенным чучелом. > Во, полюбуйся, https://habrahabr.ru/post/338880/ - очень дельно пишут. Представляешь, вебари > массово переполняют буфера даже когда им доступ в память вроде бы > уж зарубили. Ай. Ещё один диванный специалист, с доморощенным проектом нового интернета, который знает наилучшие способы решения всех проблем. Мне до сих пор неясно, почему интернет, набитый специалистами такого класса, до сих пор ещё не стал идеальным с технической точки зрения.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	58. "Переполнение буфера в функции glob  из состава Glibc"	+/–
	Сообщение от Аноним (??) on 26-Окт-17, 20:59
	> Какая им разница, на чём написана библиотека? Типы данных, удобство сборки, а при необходимости и патчинга, etc. Опенсорсом, понимаешь ли, пользуются потому что его можно взять и пропатчить. Какие-нибудь питонисты привыкли что скоростные либы за них пишут какие-то более развитые существа, а им этот код понять и менять не дано, только склеивать кирпичи между собой. Но вот сишникам это не нравится, и опенсорсом они еще и реально пользуются. > Ой, да ладно. Откуда ты знаешь? Ты уже предлагал им такую и > они отказались? Поделись опытом, мне очень интересна их аргументация. Как минимум я такой либой пользоваться не буду. Аргументация выше. Нах мне хипстокомпилер с встроенным менеджером пакетов и/или неизменяемая либа? Весь пойнт опенсорса в том что я могу взять и поменять что мне не нравится. А если тебе это все надо - вон redox os есть, еще и микроядро с той же аргументацией. Пользуйся наздоровье. > Ну и отлично. Теперь можно, заглядывая в код glibc, не исследовать возможности > оптимизации заново, а просто повторить то, что уже сделано, но без > переполнений буферов, без целочисленных переполнений, и без прочего гумна, Очередной волшебник который решит все проблемы, позволит не думать при написании программ, ога. На примере вебни и мозилабраузера видели уже. Но почему-то взламывают через эту самую вебню, а чтобы кого-то через переполнение буфера вообще огрели, со всеми ALSR и stack protector-ами - теоретически, так, наверное, бывает, но практически все атаки которые на слуху были совсем не через это. Вот рут через башскрипты по DHCP, инжекшн кода в спрут на яве, мозилла как сканер диска для АНБ - это да, помню. Только си там был вообще не у дел. > которое отловить в C невозможно даже статическим анализатором. Поэтому есть asan (и прочие ubsan, tsan, ...). Они не панацея, но переполнение буфера ловится неплохо. Очевидные ляпы с integer-ами нынче ловит компилер. А неочевидные... если чикерить результат каждой математической операции - ЭТО УБЬЕТ СКОРОСТЬ МАТЕМАТИКИ В РАЗЫ! Чтобы было быстро и эффективно, есть только 1 нормальный путь: железо должно кидать exception если математика переполнилась (и не делать ничего если все ок). И с буферами так же. До интеля в новых процах даже дошло (MPX и проч). Почему остальные тупят столько десятилетий я не знаю. > и поэтому придётся осознанно писать на rust'е код, который может переполнить буфер, > используя для этого unsafe. Но в libc предостаточно кода, который может переполнить > буфер не потому, что стандарт к этому принуждает, а просто так, по фану, и вот от > этого фана libc вполне можно избавить. Если си избавить от фана - это уже не си будет. Пользуйся своим rust-ом если тебе надо. Тогда и либы будешь вызывать безопасные, и переполнений не будет. Но глядя на вебню, и как мозиле 0day через JS вкатили, имхо кажется толку будет мало. Програмеры или научатся defensive thinking при работе с внешними данными или их будут нагревать. > блестяще побеждать в битве с соломенным чучелом. Да нет никакой особой битвы, есть немного defensive thinking и вера в себя вместо веры в рантайм и ЯП. > Ай. Ещё один диванный специалист, с доморощенным проектом нового интернета, Ну да. Однако ж дело говорит. Не нравится этот диванный, есть DJB. Он более фундаментально высказался, но идея похожая. Поэтому у него код безопасный даже на си, а у раздолбаев дыры и на питоне, и на рубях и на пыхе, и с js. > который знает наилучшие способы решения всех проблем. Он занимается тем же чем и ты, кстати :). Но его спич мне кажется более дельным чем твой. Знаешь почему? Больше коррелирует с наблюдаемой реальностью и вроде бы технически все шито-крыто. > Мне до сих пор неясно, почему интернет, набитый специалистами такого класса, > до сих пор ещё не стал идеальным с технической точки зрения. Ээээ а можно у тебя это же самое спросить про либцу на rust? :D Твои слова очень хочется сказать ... тебе! Поразвелось тут верунов в магические пули вместо думания головой. Ты один из них.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	60. "Переполнение буфера в функции glob  из состава Glibc"	+1 +/–
	Сообщение от Ordu (ok) on 27-Окт-17, 01:43
	>> Ай. Ещё один диванный специалист, с доморощенным проектом нового интернета, > Ну да. Однако ж дело говорит. Может ты и прав, для кого то его писанина и может выглядеть умно, наверное. > Не нравится этот диванный, есть DJB. > Он более фундаментально высказался, но идея похожая. Поэтому у него код > безопасный даже на си, а у раздолбаев дыры и на питоне, > и на рубях и на пыхе, и с js. Да-да. Знаем-знаем. >> который знает наилучшие способы решения всех проблем. > Он занимается тем же чем и ты, кстати :). Но его спич > мне кажется более дельным чем твой. Знаешь почему? Больше коррелирует с > наблюдаемой реальностью и вроде бы технически все шито-крыто. Это вебпрограммист, который совершенно неприспособлен к системному мышлению. Если тебе это не ясно из чтения его текстов, я могу пояснить на примере. Возьмём sql-injection. Собственно я дальше не читал, поэтому других примеров не будет. Мне одной этой глупости хватило. Тот умник говорит "я знаю как решить проблему" и начинает размахивать шашкой, забыв остановиться и подумать: в каком месте возникает проблема? В результате он начинает создавать костыли, которые могут улучшить ситуацию, которые могут усложнить проведение атак, но они не снимут проблему. Как возникает sql-injection? 1. Клиент составляет запрос, который правильный синтаксически, но семантически, с точки зрения клиента неправильный. 2. Запрос передаётся серверу. 3. Сервер выполняет запрос. 4. Результат выполнения запроса передаётся клиенту. 5. Клиент получает результат не того класса, на который рассчитывал, но он слишком тyпoй, чтобы заметить косяк, поэтому дальшейшее поведение клиента становится совершенно идиотским. На каких шагах здесь возникают ошибки? Может быть на шагах 2 и 4, то есть при передаче? Нет ведь, передача здесь не при чём. Может быть дело в том, что сервер неправильно понимает переданный ему запрос? Нет же, он понимает его ровно так, как он составлен. Но откуда может взяться вера в то, что изменение протокола передачи данных изменит ситуацию? И я даже скажу откуда: нет у человека системного мышления, он не в состоянии дифференцировать систему на части здравым образом, он произвольным образом сливает разные части системы в один флакон, и пытается после этого анализировать их работу. Видны попытки занимаеться самосовершенствованием, пытаясь проектировать системы, но он безнадёжен, потому что просто проектируя лучше не стать, надо реализовывать свои проекты и получать граблями по лбу. Совершённые ошибки учат, несовершённые только захламляют интернет тупыми постами. Ошибки возникают на шагах 1 и 5. Клиент составляет запрос неправильно, не так как задумано, программист не смог изложить свои мысли внятно. И тут уже не важно бинарный протокол или текстовый, если клиент может позволить себе составлять неправильный текстовый запрос, он точно так же может позволить себе неправильно составить бинарный. Да, я соглашусь, при бинарном протоколе, вероятно, будет сложнее совершить ошибку, которую можно эксплуатировать для чего-то кроме DoS, но DoS тоже плохо, при этом нет никаких гарантий, что невозможно получить более интересных эксплуатаций. Чтобы одолеть ошибки на шагах 1 и 5 надо выгнать поганой метлой всех вебмакак и посадить на их место квалифицированных программистов. То есть программистов, которые умеют создавать API или системы тестирования кода, которые *гарантируют* невозможность совершения ошибок опредлённого класса, например, ошибок при составлении SQL запросов. Вебмакаки не умеют составлять запросы иначе, кроме как конкатенированием строк. Я не знаю почему так происходит, то ли они тупые как пробки, то ли они считают что конкатенировать строки круто и признак ума, то ли им просто нacpaть на безопасность -- не знаю. Но все эти проблемы вполне можно решить, причём в языке со статической и достаточно развитой типизацией все ошибки типа sql-injection можно отлавливать на этапе компиляции. Но вебмакаки не компилируют. И даже динамической типизацией они пользоваться не умеют (впрочем на динамической типизации могут возникнуть существенные накладные расходы в рантайме на создание куч временных объектов и выполнение туч проверок, хотя это, как правило, решается, пускай и небесплатно с точки зрения юзабилити). Поэтому мы имеем то, что имеем. И надо быть вебмакакой на всю голову, чтобы верить, что переход на бинарный протокол интернета сможет сделать вебмакак умнее. Может быть бинарный протокол и будет полезен, но не для решения проблемы sql-injection, потому что это чистой воды проблема качества клиентского кода. С XSS на самом деле то же самое, просто надо сесть, грамотно разбить общую систему на отдельные блоки, отследить взаимодействие между блоками, и понять где именно и каким образом возникает ошибка. Где происходит потеря или искажение информации.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема