В конце прошлого года во время уборки в вычислительном центре Университета Юты была обнаружена архивная магнитная лента с кодом операционной системы UNIX V4, которая была разработана в 1973 году для ЭВМ PDP-11/45 и считалась утерянной. UNIXv4 продолжал развитие выпущенной за год до этого операционной системы UNIXv3, в которой впервые был использован язык Си и неименованные каналы. Особенностью UNIXv4 стала переработка ядра на языке Си. Код ядра UNIXv4 был написан Кеном Томпсоном, а драйверов - Деннисом Ритчи...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64498
> Восстановлен код UNIXv4, первой ОС с ядром на языке C.
> продолжал развитие выпущенной за год до этого операционной системы UNIXv3, в которой впервые был использован язык Сичто-то я ничего не понял. в v3 ядро было не на си? нужно почаще вставлять "впервые" в новость, и всё будет хорошо
Таки сходивши по ссылкам, подтверждаю — у v3 ядро было на асме.
Конь-пилятор Си уже был, но сам юникс ещё не переписали. Могу порекомендовать книгу "Время UNIX" Брайан Керниган (тот самый из Керниган и Ритчи) об истории создания unix.
> что-то я ничего не понялТебе не впервые.
Си был исконно с первейших версий придуман чтобы писать овнокод по типу такого while(*q++ == *p++); в su.
Пользуйся
Сомнительно, но Окэй.
Зато без begin-end-ов :) И что только сишники не придумают, лишь бы на паскале не программировать.
Да программируйте хоть на Оббероне, никто вам не запрещает. У сишников свой путь, у begin/end'щиков свой.
В паскале есть указатели, а это значит, что паскалисты - латентные сишники, портящие память.
Pascal относится к memory safe языкам (как и Delphi, Ada и тд)
Не нужно придумывать. https://wiki.freepascal.org/Memory_Management#Use-After-Free
>Use-After-Free on the other hand can result in unpredicted behavior, and may even result in exploitable vulnerabilities through which an attacker could trick your program into executing malicious code, or circumventing other security mechanisms such as access control.Для memory safe нужно либо отказаться от указателей, либо иметь крайне продвинутую систему типов.
Так у Free Pascal'я система типов как раз продвинутая: есть
- небезопасные указатели для обраб. данных на низком уровне ( ^T );
- безопасные указатели ( T, T- это класс);
- управляемые указатели ( которые на тип-интерфейс), они как smart pointer;
- динамические массивы и строки - у них память освобождается автоматически.
>Так у Free Pascal'я система типов как раз продвинутая: естьЗависимые типы в паскале есть? Нет? Ну значит продвинутой системы типов нет.
>- небезопасные указатели для обраб. данных на низком уровне ( ^T );Здесь сразу же нужны зависимые типы как минимум. Афинные типы тоже понадобятся.
>- управляемые указатели ( которые на тип-интерфейс), они как smart pointer;С зацикливанием и утечкой памяти?
>- динамические массивы и строки - у них память освобождается автоматически.Как именно?
Для 1990-ых это может и было интересно, но для 2026 этого уже очень мало.
> Pascal относится к memory safe языкамНе относится, потому что память в нем ты ручками вычищаешь. Даже C++ к ним не относится, а в нем, на минуточку, в отличие от Паскаля/Delphi есть RAII.
https://wiki.freepascal.org/smartpointers
> https://wiki.freepascal.org/smartpointersОго!
Это то до чего дыряшечникам еще топать и топать.
Они пока только осилили добавить Bool вместо макросовой дрыcтни.
> память в нем ты ручками вычищаешьу тебя сильно устаревшие сведения, в паскале давно уже есть управляемые типы.
> у тебя сильно устаревшие сведения, в паскале давно уже есть управляемые типы.Ну покажи мне автоматически вычищающийся TStringList.
> есть указатели, а это значит, что паскалисты - латентные сишники, портящие память.В расте есть unsafe, а это значит, что растисты - латентные сишники, портящие память.
Чётко подмечено!
Pascal сформировался в своём классическом виде только в 1974-м году, и он был предназначен для программирования in small.
Программа на Pascal должна находиться только в одном файле исходного текста, о каком серьёзном применении Паскаля может идти речь?
(TurboPascal, Delphi, FreePascal, GnuPascal, IsoPascal, MacPascal - это не Pascal, это другие языки)
> Программа на Pascal должна находиться только в одном файле исходного текста, о каком серьёзном применении Паскаля может идти речь?Покажи мне хоть одну программу из исходного кода Unix 4 (ссылка в новости), которая состояла бы из более чем одного файла исходного текста. То-то же...
Ядро
> TurboPascal, Delphi, FreePascal, GnuPascal, IsoPascal, MacPascal - это не Pascal, это другие языкиСи сформировался в своём классическом виде только в 1999 году. Программа на Си представляет собой портянку из инклудов, завёрнутых в макросы, чтобы инклуды не зацикливались, вызывая самих себя рекурсивно. Это надо делать вручную, в отличие от более продвинутого Паскаля, где есть модули. GCC, Clang, MSVC, TCC, Turbo C, Watcom, Oracle Solaris Studio C, Pelles C, K&R C, ANSI C, C99, C11, C17, C23 - это не Си, это другие языки.
(Чтобы тебе был понятен ответ, подскажу, что Delphi - это не язык).
> Программа на Pascal должна находиться только в одном файле исходного текста, о каком серьёзном применении Паскаля может идти речь?Ты не поверишь, но в Си тоже! Тебе сишочный код из разных #include в одну портянку склеивает левая приблуда (макропроцессор).
Склеивает только заголовочные файлы, а единицы трансляции (т.е. файлы .c) остаются на месте.
> Си был исконно с первейших версий придуман чтобыМожно было бы ещё раз объяснить тебе, для чего был придуман Си, но тебе уже объясняли, а ты так и не понял.
Оператор ++ был взят из Algol-68
В чём глубинный смысл писать Си вместо C?
Зря заминусили, вообще-то под Юниксом неиронично предполагалось сишку использовать для мелких утилит, вызываемых через shell & awk.
> Код содержал уязвимость, приводящую к переполнению буфера из-за копирования
> вводимого пользователем пароля в фиксированный 100-символьный массив без проверки
> размера вводимых данных.Реликтовый вулн дидов. Почти как первая ошибка ворлонов с которой начались их неудачи и обломы.
На ассемблере по другому и не напишешь. Или придется городить огороды размером больше самого приложения на каждый чих.
>На ассемблере по другому и не напишешь.Сразу видно авторитетного писателя на асме :)))
Охх, ты ж! Вавилон 5 подкатил!
+ за Вавилон-5. В условиях ограниченных ресурсов (каждый байт за счету) такое отношение к переполнениям буфера имело место быть... но в современных условиях такое уже недопустимо.
> Почти как первая ошибка ворлонов с которой начались их неудачи и обломыЭто какая же?
> Это какая же?"Синдром вахтёра".
Бот скрывает ответ... Ответ: "синдром чрезмерного величия при своём не очень высоком положении".
> Бот скрывает ответ... Ответ: "синдром чрезмерного величия при своём не очень высоком
> положении".Ну, относительно других цивилизаций положение у них было достаточно высоким, если не считать Теней.
>> Почти как первая ошибка ворлонов с которой начались их неудачи и обломы
> Это какая же?Ворлоны очень развитая раса, помешанная на порядке и правилах. Они познали многие тайны вселенной, достигли вечной жизни и даже возможности расщепления своего разума на инстансы, не говоря о мелочи типа "направления развития" более новых рас и милых шалостей типа патчинга генотипа под свои нужды. Они стали считать себя самыми умными в вселенной. Что достигли почти всего. И нет никого равного им. Что могут указывать другим как жить и что делать. Однажды они обнаружили что кроме обычной вселенной и гиперпространства есть еще что-то. Называемое "third space". И конечно они запилили туда гейтвей. Что может пойти не так с гейтвеем, если его сделает раса самоуверенных всезнаек?
Оказалось что третье измерение населено еще более развитой расой, победившей все остальные. Они ненавидят все разумное что не они и уничтожают других на корню. И настолько продвинуты, что вскоре многие ворлонцы и их корабли просто перешли под контроль разума этой расы - и стали воевать против своих. Ворлонцы чуть не сыграли в ящик и чуть не угробили всю галактику, и лишь чудом избежали участи остальных рас угробленых этими милашками. Говорят что это была первая ошибка, с которой начались остальные ошибки и неудачи у расы всезнаек помешанных на порядке.
Помню как разработчики sendmail в начале 1990-х отказывались править переполнение буфера, мотивируя тем, что вызывающий переполнение SMTP-запрос не соответствует RFC. Типа, запросы, соответствующие RFC обрабатываются без ошибок, значит всё Ок.
Сейчас перекладывание ответственности вышло на новый уровень, теперь пеняют не на RFC а на зеркало перед юзером. Типа мы тебе из коробки сломали вызывающий впросы функционал, но на свой страх и риск ты его можешь включить тут. Что? Базовый функционал говорите? Ну да... мы тебе из коробки сломали базовый функционал, но на свой страх и риск ты его можешь включить тут.И одно дело когда то нтфс на запись, а другое - когда нода там или томкет.
Для тех кто помнит pe2 (dos)
https://snobol5.org/pe3doc.htm
работающий редактор на SNOBOL !!!
> приводящую к переполнению буфера
> "кому может понадобиться вручную вводить слишком длинные строки".У них никогда не было кота?! Или детей?
(Не, ну детей к дорогущему компу может и не подпускали)> мало кто обращал внимание на переполнения буферов
И с того времени мало что изменилось :)
А котов типа подпускали? Тогда если ты там что-то переполнил ты не в другой стране сидишь, а в специализмрованном помещении с пропускной системой и охраной. Если что-то сломал, охрана будет сначала бить, а потом думать. Вот и не было переполнения тогда. Грамотное обустройство рабочего пространства.
> А котов типа подпускали?а что ты коту сделаешь в его квартире? ты обслуга, подай-принеси, не более
Какой pdp-11 в квартире?
Электроника БК-0010 же!
Это pdp-11 курильщика
> Это pdp-11 курильщикаОй! Не придирайтесь!
Как смогли - так и сп###ли.
Скажите спасибо что хоть это было))
"в квартире" - вот и дожили, когда у молодняка на уме только "комп в квартире"))
Вот и дожили, когда у молодняка на уме только квартиры. Про пещеры совсем забыли. Потерянное поколение.
А котам туда нельзя. Сюда нельзя.
Какие коты??
Просто коpоpaтивный paб устав грести на гaлepe упал моpдой лица прям на клавиатуру терминала. И набрал больше чем 100 символов.Хотя на самом деле все было проще.
"Dennis once fed a couple-of-thousand-byte line on standard input to everything in /bin. Crashes abounded, but so what? Wasn't a crash just an ungraceful way for a program to say "I can't handle this"? Not until the Morris worm (1988) did folks wake up to the real danger of overflows." - слова того же Макилроя.Им было просто плевать на качество, на безошибочность, на надежность.
Реальность потом ударила по лицу, но привычка писать дpmовый код уже пошла в (kalовые) массы СИшников.
>Им было просто плевать на качество, на безошибочность, на надежность.А вот тут явно передёргиваешь.
>>Им было просто плевать на качество, на безошибочность, на надежность.
> А вот тут явно передёргиваешь.Блин, я спецом привел цитату
"Crashes abounded, but so what?"В ней прямым тесктом написано "Упало? Да поxep!"
Все осознанно.Там штучный суперкомп аж на 256кб памяти, что в миллион раз меньше чем сейчас у любого на столе.
>Им было просто плевать на качествоТы так говоришь, как будто сейчас что то изменилось. Нет, просто за время компьютерной эпохи напридумывали костылей, которые мало по малу поддерживают "писателей". У меня нет сомнений, что если посадить рядом дидов и современных вебописателей и выдать им одинаковые инструменты, то результат будет не в пользу современных поколений.
> Ты так говоришь, как будто сейчас что то изменилось.Да, изменилось.
Как минимум прользователь будет расстроен если его комп или телеон ломанут.А для программеров такой маневр может стоить работы, а его компании вообще существования (попадаешь на штраф и банкротишься).
> У меня нет сомнений, что если посадить рядом дидов и современных вебописателей и выдать им одинаковые инструменты, то результат будет не в пользу современных поколений.
Каких наƒиг инструментов?
В СИ того года не было условно оператора чтобы написать
if (sizeof(password) > validSize)
goto ohSHIT
?Чего блuн не хватало?
Или просто секономили пару строк, потому что "ну упало, ну и xul'e"))
Тогда быстродействие считали в тактах процессора. Что даёт это твоя проверка в долларах? Ненужную работу? А чего может ещё игру тетрис туда добавить?
> Что даёт это твоя проверка в долларах? Ненужную работу?А потом такие
"Бл###! Нам самокопирующийся черяк положил кучу компов! У нас убытки на 100500 баксов!
Как жи это произошло!!"Ну шо, наэкономили такты?
Не было раньше такой проблемы, как же вы не поймёте.
Хакера просто перестали бы пропускать на посте охраны в здание где комп.Это сейчас есть интернет куда легко попасть из любого места и потом тебя трудно найти, а ты можешь кому угодно что угодно слать.
Какой самокопирующийся червяк в 1973-м году? Тогда весь ARPANET состоял из пяти компьютеров, и там точно был не Unix.
> Какой самокопирующийся червяк в 1973-м году?В 1988.
> Тогда весь ARPANET состоял из пяти компьютеров, и там точно был не Unix.
Там был таки юникс.
В UNIX System V (1983) овнокод переехал вообще без изменений.
Пруф: github.com/ngn999/UNIX-System-V/blob/182dea74d55cb447d1b0adba2d62b8f8cdcdd392/usr/source/s2/su.c#L4
> Тогда быстродействие считали в тактах процессораИ именно поэтому они дергали getc() в цикле?
https://github.com/Equilateral-AI/UnixV4-Resurrection/blob/m...
while((*q = getchar()) != '\n')
Хотя, ты небось код даже не смотрел, не так ли?
Там поди какойнить gets(buff); используется для чтения ввода, он не умеет в размер буфера.
https://www.geeksforgeeks.org/c/gets-in-c/
> Там поди какойнить gets(buff); используется для чтения ввода, он не умеет в размер буфера.А взять и код посмотреть ты не в состоянии?
https://github.com/Equilateral-AI/UnixV4-Resurrection/blob/m...
while((*q = getchar()) != '\n')
gets() внутри как раз и соедржит примерно это.
Долгое время данное не было проблемой ПО/владельца системы а было проблемой юзера который делает что то не то.
скорее всего тогда ещё не было sizeof(), пишут, что он появился во времена Unix V5 и V6, примерно тогда, когда и структуры.
ну на самом деле его там не было потому что размеры на pdp11 и так все знали, зачем считать то что заранее известно.
А появился при переносе на interdata (и это скорее v6) когда внезапно оказалось что на другой архитектуре в int не два char а целых четыре и это надо как-то уметь проверять, если данные читаются или пишутся посимвольно из внешнего источника.А byte не появился, ненавижю.
держи:typedef unsigned char byte;
> ну на самом деле его там не былоНа самом деле он там есть:
https://github.com/search?q=repo%3AEquilateral-AI%...
> его там не было потому что размеры на pdp11 и так все знали, зачем считать то что заранее известно.
Очередной опеннетный эксперт сочиняет чушь о том, как оно там в семидесятых было "на самом деле". 🤦
> скорее всего тогда ещё не было sizeof(), пишут, что он появился во времена Unix V5 и V6, примерно тогда, когда и структурыПисаки врут, ибо sizeof в исходниках есть:
Ну вот упал он лицом и куда-то там вышел. Комп завис, и? Какая угроза пойяси. Лишний раз перезагружаться? Ну так перезагрузись не быкуй.
Это все еще в UHG описано. Весь евнухс таким всегда был.
Вряд ли кто-то пускал котов или детей в офис Bell Labs, и уж тем более в помещения с компьютером.Тогда к этому относились как к рабочему инструменту для профессионала. Оперативная память измерялась в килобайтах. Каждая лишняя проверка на счету. Без особой необходимости - слишком расточительно.
А потом на этой кодовой базе сделали стек для ARPANET, и открылась целая новая реальность:)
> Оперативная память
> Без особой необходимости - слишком расточительно.Ага, и поэтому мы выделим 200 байт стека на пароль.
> Каждая лишняя проверка на счету
И поэтому мы будем дергать getc() в цикле.
Как же смешон копиум местных экспертов. Хотя, казалось бы, вот же код и даже цитаты Дугласа Макилроя под носом...
> И поэтому мы будем дергать getc() в цикле.У вас есть pipe/socket, вам нужно прочитать из него строго одну строку ввода, потому что код дальше будет читать следующую строку.
Как вы будете это реализовывать кроме чтения по одному символу в поисках '/n'?
> утилита включала менее 50 строк кода
> переполнению буфера из-за копирования вводимого пользователем пароля в фиксированный 100-символьный массив без проверки размера вводимых данных.Ахахаха, диды писали!
Вот и ответ на вопрос "сколько строк на СИ достаточно чтобы написать CVE")))> Код ядра UNIXv4 был написан Кеном Томпсоном, а драйверов - Деннисом Ритчи.
Есть ли более настоящие СИшники чем эти два?
> Добавление проверок размера вводимых вручную данных рассматривалось как добавление лишнего кода
И тааак сойдет! (с)
> аварийное завершение при переполнении воспринималось как неуклюжая форма реагирования на некорректные входные данные.
Поэтому мы просто не будем реагировать. Никак.
Испортим память или подарим рут доступ.
То ли дело CVE в Binder.
CVE в Binder привело к падению.
Память не была испорчена, повышение привилегий или исполнение чужого кода не произошло.К чему приводят CVE в СИшной дpыстине мы читаем вот прям на этом сайте каждую неделю-две.
Нужно заметить, что пальму первенства постепенно перенимает Rust и каждую неделю-две в коде на нем обнаруживаются удивительные CVE. Оно и понятно, учитывая невозможность писать что-то больше перекладывателя байтов с места на место без помощи ИИ.
> Нужно заметить,Пруфы бы.
А то твое сообщение выглядит как нейрокал без каких либо доказательств.
Что очень печально.
1 rust CVE на 500 Си CVE в ядре в среднем. Ближайшие годы Сишники пальму не отдадут, даже если количество кода на rust перевалит за половину.
Только большинство CVE в C - это какая-нибудь утечка памяти, которую еще придется потрудиться реализовать, когда как в Rust бэкдор можно просто напрямую в код встраивать все равно никто не разберется.
Причем память у Си утечет вместе с рутом.
При этом кода на Си в миллион раз больше.
Проблема в том, что cve на rust одна единственная, и повод для целой новости, а 500 cve на дыряшке обыденность, и никого не удивляет, что 500 приходится на один раз. Будут следующие 500, об этом опять же никто как о целой новости не напишет.
> CVE в Binder привело к падению.Память не была испорчена, повышение привилегий или исполнение чужого кода не произошло.
Да, подумаешь, произошёл DoS всей системы, с кем не бывает. Всего-то навсего обошли систему упреждения race-condition (если она вообще существует) в safe коде. А, да, точно, "виновата" строчка unsafe где буквально происходит обычное удаление элемента из списка, а не та safe часть кода, которая отпустила лок на лист, продолжая работать с данными из него, пусть даже сделав локальную копию (нахера?).
> Да, подумаешь, произошёл DoS всей системы, с кем не бывает.Нет, это большая проблема.
Но с RCE было бы все гораздо хуже.> А, да, точно, "виновата" строчка unsafe где буквально происходит обычное удаление элемента из списка, а не та safe часть кода, которая отпустила лок на лист, продолжая работать с данными из него, пусть даже сделав локальную копию (нахера?).
Да, работа с unsafe кодом требует внимательности.
Unix V4 - дата создания 1973 год.
UUCP (первые хоть какие-то сетевые средства) - дата создания 1976 год, более-менее широкое внедрение 1978 год (было подключено аж 82 машины внутри Bell Labs).
Сетевой стек (4BSD, уже не совсем, и даже совсем не Unix V4, а что-то около Unix V7) - дата создания 1981 год.Т.е. удалённо этой уязвимостью воспользоваться никак не получилось-бы.
Далее - тогда ещё в разные ROP (Return-Oriented Programming) не умели, да и букв таких не знали, поэтому максимум что Вы могли - это обеспечить SIGSEGV, который обеспечивало ядро ОС. Современные языки при переполнении буфера вызывают абстрактный panic(), который, по итогу, выполнит практически то-же самое, только без участия ядра.
А кто сказал что это код не перекочевал дальше?
Вот напр. тот же файл в UNIX V
github.com/ngn999/UNIX-System-V/blob/182dea74d55cb447d1b0adba2d62b8f8cdcdd392/usr/source/s2/su.c#L4
Тогда неисполнимых стеков не было, какой еще нафиг ROP.
> 93-летний Дуглас МакилройОн может гордиться следующими поколениями, которые совершают абсолютно такие же ошибки в 2025м что и они в 1973м.
Вот она настоящая преемственность поколений!
Пронесем сишные дыры через века!
Нынешнему поколению плевать даже на сам Си не то, чтобы на баги Сишные, даже не с точки зрения безопасности, а вообще корректности того или иного алгоритма. Формализм на то и формализм, что думать особо о имплементации не надо. Написал f(x) = y, ну вот и все, и не должно волновать никого кто и что за место этого икса туда пихнет.
>Нынешнему поколению плевать даже на сам Си не то, чтобы на баги Сишные, даже не с точки зрения безопасности, а вообще корректности того или иного алгоритма.То-то же современные программисты пишут либо на rust, либо на ocmal, либо на haskell, где ошибочная программа, в отлчии от си компилироваться не будет. А ведь есть ещё Lean и Idris.
> современные программисты пишут либо на rust, либо на ocmal, либо на haskellАга, все три современных программиста пишут именно на этом. Один - на расте, второй - на окамле, третий - на хаскеле. А все остальные 99.9999999% программистов пишут на js, java, python и c++.
> То-то же современные программисты пишут либо на rust, либо на ocmal, либо
> на haskell, где ошибочная программа, в отлчии от си компилироваться не
> будет. А ведь есть ещё Lean и Idris.Почему-то в топах рейтингов яп совсем другие языки. А на каком месте там haskell и ocaml это вообще никто не скажет.
Налепили, прибили, скотчем примотали и в продакшн. Думать они начали с выпуском Plan 9, но уже было поздно
В совке и такого не было.
ДЕМОС. Но не уверен в её лицензионной чистоте.
> Добавление проверок размера вводимых вручную данных
> рассматривалось как добавление лишнего кодаБугуга, с тех пор ничего и не изменилось)))
Зато пару тактов можно будет сэкономить.Хотя нет, не пару...
В недоязычке нет строк, а длина char* считается за O(N).
А за какое время в расте длина char* считается?
1. А причет тут раст?
2. В нормальных языках есть тип String, в котором при создании записывается кол-во символов.
Это позволяет оперировать с длинной строки (например создавать буфер нужного размера) без её обхода.
> А за какое время в расте длина char* считается?В расте есть нормальные строки вместо char*
И их длина считается за O(1) - там просто возвращается значение.pub const fn len(&self) -> usize {
self.vec.len()
}
doc.rust-lang.org/src/alloc/string.rs.html#1849
doc.rust-lang.org/src/alloc/vec/mod.rs.html#2912
Таких "нормальных строк" в С в разных либах/фреймворках вагон и маленькая тележка, просто их никто в стандарт не тащит, потому что это лишнее.
> просто их никто в стандарт не тащит, потому чтоНе лезут. Чтобы структура вела себя как указатель, дополнительно хранящий размер, нужна перегрузка операторов.
Си - это не только близость к железу, но и реалии 70...80-х. Что общего между "%zd" и PRId8? То, что это нормальный подход для 70-х, компайл-тайм наворотов в портативном ассемблере быть не могло, жертвовать здесь производительностью, размером бинарника и нервами разработчика было нормально - ничего лучше вокруг нет и не надорвётся он с тогдашними объёмами кода.
Какая перегрузка операторов? Зачем?
Структура { длина, указатель } - это совершенно _другой_ тип данных. Для него пишутся другие функции по определению, стандартные все равно не годятся. Вот Игорь Сысоев не поленился и написал для nginx:https://github.com/nginx/nginx/blob/master/src/core/ngx_stri...
> Структура { длина, указатель } - это совершенно _другой_ тип данных. Для него пишутся другие функции по определениюВерно, в Си ещё с обобщённым программированием проблемы. Только на макросах, а их даже ты тут не рассматриваешь.
> стандартные все равно не годятся
И со стандартной библиотекой, да.
А смысл их тут рассматривать? Только если сделать комбо, когда строки нуль-терминированные, но ещё с собой таскается длина для оптимизации. Тогда ещё можно что-то разумное придумать.Полноценное обобщенное программирование - это не для продвинутого макроассемблера, слишком далеко от железа, для этого есть более другие языки.
>Чтобы структура вела себя как указатель, дополнительно хранящий размер, нужна перегрузка операторов.Зачем? Достаточно выкинуть текущие строковые функции типа printf и strcpy и вместо них воткнуть нормальные. Сишникам не лень писать разные операторы для доступа к полю в структуре и по указателю, вот и тут бы не облезли.
> Таких "нормальных строк" в С в разных либах/фреймворках вагон и маленькая тележка,Велосипеды! Покупайте наши велосипеды! Они самые велосипедистые в мире!!
> просто их никто в стандарт не тащит,
Потому что "стандарт" такой же кусок крэпа.
> потому что это лишнее.
Ага, как и bool, который 50 лет был "ненужон ваш bool! хватит и макросной дрыстни!"
Но ВНЕЗАПНО в С23 добавили.Так что ждем строки.
Лет через 20ть))
А зачем нужны строки?Так по хорошему в С есть строки, это то что const char * = "stroka";
Всё остальное это какие то байты хранящиеся где то в памяти, про которые известно программисту но не компелятору.А когда программе надо много работать со "строками" - тогда и юзают всякие или самописные или готовые фреймворки для строк, где длина хранится где то рядом.
> А зачем нужны строки?
> Так по хорошему в С есть строки, это то что const char * = "stroka";Ну, например, чтобы не бежать каждый раз O(n) в поисках нуля? Причем заметь: компилятор-то уже знает длину строкового литерала, но гениальный дизигн "на коленке" в 99% случаев это не позволяет использовать.
Ну, или, не сношаться с буферами фиксированного размера в случае, как вот с этим дырявым дидовским su. Уже больше полувека целый пласт вулнов льется бесконечным потоком лишь потому, что в Си отсутствует человеческий строковый тип. Причем первопроходцами в этом стали сами деды-создатели! 😂
Если у тебя проблемы с тем, чтобы писать код, в котором нету перепрыгивания через '\0', то у тебя такие же проблемы будут с любыми другими делениями по токенам типа разночтения окончания строк (CRLF vs. LF), пробелов, тегов в XML и т.д.. Иди поспи. Если не помогло - брось это дело, у тебя не получается. Можешь на баше попрограммировать, там за тебя уже позаботились о пресловутом поиске нуля в конце строки (который ищется быстрее, чем какой-нибудь питон свои строки переаллоцирует 10 тысяч раз и перепроверит на правильность кодировки, так, чисто на всякий случай, всё равно ты никуда не торопишься).
> Если у тебя проблемы с тем, чтобы писать код, в котором нету перепрыгивания через '\0'С этим проблемы есть у всех сишников уже более полувека. Начиная, вон, с дидов-основателей.
А у тебя нет, я правильно понял твой намек? Ты тот самый "настоящий сишник"? 🤣
> Можешь на баше попрограммировать
> какой-нибудь питонВот это тебя понесло! Баш, Питон... Иди поспи, что ли.
>Если у тебя проблемы с тем, чтобы писать код, в котором нету перепрыгивания через '\0'Это сишные проблемы.
>такие же проблемы будут с любыми другими делениями по токенам типа разночтения окончания строк (CRLF vs. LF)Разные окончания строк не приводят к переполнению буфера.
>пробелов, тегов в XMLНормальные люди давным давно используют библиотеки, а не пишут обработку с нуля, словно на дворе семидесятые
>Можешь на баше попрограммировать, там за тебя уже позаботились о пресловутом поиске нуля в конце строки (который ищется быстрее, чем какой-нибудь питон свои строки переаллоцирует 10 тысяч раз и перепроверит на правильность кодировки, так, чисто на всякий случай, всё равно ты никуда не торопишьсяЕсть куча языков: rust, ocaml, go, но сишники продолжают страдать дихтомией - либо си, либо баш/питон.
> Ну, например, чтобы не бежать каждый раз O(n) в поисках нуля?А зачем?
Вы сами себе придумали проблему.
Достаточно просто рядом с указателем на область памяти хранить размер.
> Причем заметь: компилятор-то уже знает длину строкового литерала, но гениальный дизигн "на коленке" в 99% случаев это не позволяет использовать.Это вы про: const char* = "abc".
Так оно через (sizeof(X) - 1) когда надо доступно.
По скорости memcpy() vs strlcpy() не будет заметно отличатся для строк "типичной" длины (читай до 16 символов), поэтому редко кто заморачивается. По безопасности тоже отличий нет, тк /0 гарантирован для таких строк.
> Ну, или, не сношаться с буферами фиксированного размераБуфера на стёке удобны, их и освобождать не надо. Никаких сношений там нет.
В современном С мире осталось мало API где принимают только const char* без размера и полагаются на /0 в конце.
Всякие статические анализаторы кода прекрасно находят все подозительные места, если про них писатель не знал или забыл. Те проблема со строками в С не актуальна.
> Таких "нормальных строк" в С в разных либах/фреймворках вагон и маленькая тележка, просто их никто в стандарт не тащит, потому что это лишнее.Зато не лишнее - посношаться с фиксированным буфером и вылезти за его пределы.
ага, а потом пытаешься совместить эти либы в одном проекте
>> А за какое время в расте длина char* считается?
> В расте есть нормальные строки вместо char*проблема только в том что они - в хрусте.
> И их длина считается за O(1) - там просто возвращается значение.
ты и на си тоже вполне можешь заранее посчитать значение и сохранить отдельно.
Почему-то так почти никто не хочет делать. (В том числе и потому что чаще всего нам не нужно это знать вообще.)Причина банальна - в процессоре нет никаких строк. И в памяти их нет. Есть только последовательности байт.
Это просто синтаксический сахарок. Каждый раз как тебе приходится взаимодействовать с внешним миром из твоего нескучного йезычка - сахарок приходится отложить в сторонку и заново учиться работать с сырыми данными из недоверенного источника.
> проблема только в том что они - в хрусте.Да, это проблема.
Можно решить выкидыванием дырявых ЯП.> ты и на си тоже вполне можешь заранее посчитать значение и сохранить отдельно.
Желательно прикостылять где-то сбоку.
А потом забыть обносить и получить рассинхрон выделенного буфера и реального размер строки.
Отличный план нax. надежный как СИшная дpucтня!> Почему-то так почти никто не хочет делать.
СИшникам плевать на качество*?
* начиная с UNIXv4> Причина банальна - в процессоре нет никаких строк. И в памяти их нет. Есть только последовательности байт.
Ого! Ты умеешь читать педивикию!
> сахарок приходится отложить в сторонку и заново учиться работать с сырыми данными из недоверенного источника.
Вот только "сырые данные из недоверенного источника" могут читаться один раз.
А потом еще обрабатывается в 10 функциях, в каждой СИшник может налажать.
И лажает.
> В расте есть нормальные строки вместо char*
> И их длина считается за O(1) - там просто возвращается значение.Я б посмотрел как ты имеючи только асм вообще забутстрапишь свой rust хоть как-то. Особенно с его чудной полисей что текущая версия собирается только предыдущей.
Поэтому есть те кто может поднять платформу с ноля при zero assumptions. И есть все остальные. И вы никогда не будете равные первым по их эпичности, сколько бы не тявкали.
> 1973
> Кен Томпсон
> Код содержал уязвимость, приводящую к переполнению буфераХотелось бы услышать комментарии ProfessorNavigator, который любит рассказывать, что проблема в деградировавших современных программистах. Как это понимать? Или Кену Томпсону тоже капитализм подгадил?
> Или Кену Томпсону тоже капитализм подгадил?Конечно!
Проприетарный UNIXv3 переписывали для проприетарного ЭВМ PDP-11/45 в виде проприетарного
UNIXv4 и все это делалось в корпе DEC.
Чуешь запах капитализма?!
> Или Кену Томпсону тоже капитализм подгадил?Разумеется. Менеджер корпорации ̶у̶г̶н̶е̶т̶а̶л̶ ̶п̶р̶о̶л̶е̶т̶а̶р̶и̶а̶т̶ подгонял разработчиков ради сиюминутной наживы, заставлял работать в нечеловеческих условиях и не организовал правильный режим труда. А государство не предоставило им бесплатное образование, поэтому они и оказались такими некомпетентными.
А вот если бы был комунизм, то не было бы у вас ни Unix, ни PDP, ни DEC!
Сидели бы со счетами и никаких переполнений буфера не произошло бы.
ну, а в итоге кто больше дров наломал? аксиома ведь - не совершает ошибок тот, кто ничего не делает.
Но ведь вся суть существования местных комментаторов никогда не выходить заграницу буфера. Это заповедь, которую нельзя нарушать.
> Хотелось бы услышать комментарии ProfessorNavigatorНе буди лихо, пока оно тихо ;) Впрочем - уже поздно, хе-хе.
> Как это понимать?
В новости прекрасно написано - как это понимать. У вас ограничение на длину вводимой строки. Всё, что больше, считается критической ошибкой, поэтому падение программы в данном случае - нормальное поведение. Такой вот способ обработки ошибок был в то время, чтобы не городить лишний огород - процессор то слабее, чем в современной стиральной машине, и памяти, считай, нет (если сравнивать с сегодняшним днём). Впрочем, вам ведь всё равно, про таких говорят: хоть кол на голове теши. И к программированию вы никакого отношения не имеете, вы здесь за другим. Хозяин приказал - вот и страдаете ерундой, вместо того, чтобы подучиться хоть чутка.
> Или Кену Томпсону тоже капитализм подгадил?
Он гадит вообще всем, даже тем, кто так не считает. Падение уровня образования - одно из проявлений. Но и это даже не главное, главное в том, что современная система образования (любая) думать не учит совершенно. Интеллект - это умение принимать нестандартные решения. "Прокачивается" оно только одним способом - постоянной тренировкой мозгов на множестве нестандартных ситуаций. А капиталу такое не нужно - ему нужны биороботы, приставленные к оборудованию. Они в обслуживании дешевле обходятся - сами себя ремонтируют, сами себя энергией обеспечивают. Только вот беда - иногда зарплату платить приходится, иначе разбегаться начинают. Впрочем, это тоже решаемо - можно ведь закабалить кредитами так, что никуда не денутся. А если всё же попробуют - тоже не беда. Старые добрые цепи, пристёгиваемые к чему-нибудь прочному, никто не отменял.
> Такой вот способ обработки ошибок был в то время, чтобы не городить лишний огород - процессор то слабее, чем в современной стиральной машине, и памяти, считай, нетТрёхмерные крестики-нолики* (в дополнение к двухмерным), шахматы, блэкджек, генератор лабиринтов, какая-то игра-угадайка из Англии, игра "Hunt the Wumpus"... юниксовая размашистость в файловой системе, без 8.3 из CP/M и прочего. Как на это хватило памяти и процессора в 1972-1973 на дорогущем казённом компьютере? И почему история юникса всегда шла рядом с HDD на сотни дискеток объёмом?
Воу-воу!
Ты только трехмерные крестики-нолики не трож!
Это все нужно для работы.
А проверка длинного пароля роняющая утилиту, это совершенно избыточное и ненужное!!> http://squoze.net/UNIX/v4man/man6/cubic и т.д.
спасибо за ссылку))
Что характерно в казенном большом компе на несколько машинных залов в файловой системе судя по эмуляторам была папка games
Умели код оптимизировать. На моём первом ПК был жёсткий диск размером 40 Мб, сколько там по остальным параметрам было - не помню уже. Дело было больше 30 лет назад.
>У вас ограничение на длину вводимой строки. Всё, что больше, считается критической ошибкой, поэтому падение программы в данном случае - нормальное поведение.Проффесор, а читать не умеете. Нет никакого падения, есть переполнение буфера. И при вводе специальных данных, можно переписать память, выполнив произвольный код.
>Такой вот способ обработки ошибок был в то время, чтобы не городить лишний огород - процессор то слабее, чем в современной стиральной машинеИ что? Если бы в код добавили проверку на выход из буфера, то что, программа бы сломалась?
>и памяти, считай, нет (если сравнивать с сегодняшним днём)А что, сишники сейчас пользуются памятью? По прежнему экономят каждый байт, так что программы портят память в тех же самых местах.
>Впрочем, вам ведь всё равно, про таких говорят: хоть кол на голове теши.Сишники г-кодеры не потому, что пишут дырявый код. Сишники г-кодеры потому, что хотят писать дырявый код. И если у них появится возможность перестать писать г-код, то они её с радостью отвергнутю
>Падение уровня образования - одно из проявлений.Мы обсуждаем дидовый г-код, а не современный. Современные инструменты позволяют избегать таких проблем автоматически.
>что современная система образования (любая) думать не учит совершенноИнтересно, а почему это современные инструменты, позволяющие избегать таких проблем априори, появились сейчас, а не в то время, когда по вашему утверждению был более высокий уровень образования? Наоброт, в отличии от тех тёмных времён, сейчас есть интернет, а не просто местная библиотека.
>Только вот беда - иногда зарплату платить приходится, иначе разбегаться начинают.Зато при коммунизме зарплату можно не платить, а чтобы не разбегались, закрыть границы. Платить 99% по минимальному прожиточному минимум, и хватит с них.
>[оверквотинг удален]
> Мы обсуждаем дидовый г-код, а не современный. Современные инструменты позволяют избегать
> таких проблем автоматически.
>>что современная система образования (любая) думать не учит совершенно
> Интересно, а почему это современные инструменты, позволяющие избегать таких проблем априори,
> появились сейчас, а не в то время, когда по вашему утверждению
> был более высокий уровень образования? Наоброт, в отличии от тех тёмных
> времён, сейчас есть интернет, а не просто местная библиотека.
>>Только вот беда - иногда зарплату платить приходится, иначе разбегаться начинают.
> Зато при коммунизме зарплату можно не платить, а чтобы не разбегались, закрыть
> границы. Платить 99% по минимальному прожиточному минимум, и хватит с них.Код, написанный лично вами, покажите, потом продолжим.
Вы уже в соседней теме видели мой код, забыли?
> Вы уже в соседней теме видели мой код, забыли?Он не ваш, а из методички. Когда свой проект напишите, или в чужой вклад вносить начнёте - приходите. В общем - свободен.
>Он не ваш, а из методички.Ну так вы любой код не моим назовёте, даже если я его при вас напишу. Скажете, что зазубрил на память.
>или в чужой вклад вносить начнёте - приходитеА кто вам ошибку в вашем парсере указал, а?
> Ну так вы любой код не моим назовёте, даже если я его
> при вас напишу. Скажете, что зазубрил на память.
>>или в чужой вклад вносить начнёте - приходите
> А кто вам ошибку в вашем парсере указал, а?Свободен.
> У вас ограничение на длину вводимой строки. Всё, что больше, считается критической ошибкой, поэтому падение программы в данном случае - нормальное поведениеАга, за исключением тех случаев, когда пределы буфера не приводит к падению. Или (как это su) оставляет тебя с вырубленным режимим TTY echo. Нормальное поведение, да.
> Такой вот способ обработки ошибок был в то время, чтобы не городить лишний огород - процессор то слабее, чем в современной стиральной машине
И поэтому мы дергаем getc() в цикле.
> и памяти, считай, нет
И поэтому мы наперед откусим 100 байт стека.
> Впрочем, вам ведь всё равно, про таких говорят: хоть кол на голове теши. И к программированию вы никакого отношения не имеете
О, превентивный ad hominem от профессора. 😂
>> Или Кену Томпсону тоже капитализм подгадил?
> Он гадит вообще всем, даже тем, кто так не считает. Падение уровня образования - одно из проявленийНамекаете, что Кен Томпсона был тот самый "упавший" уровень образования?
>[оверквотинг удален]
> Нормальное поведение, да.
>> Такой вот способ обработки ошибок был в то время, чтобы не городить лишний огород - процессор то слабее, чем в современной стиральной машине
> И поэтому мы дергаем getc() в цикле.
>> и памяти, считай, нет
> И поэтому мы наперед откусим 100 байт стека.
>> Впрочем, вам ведь всё равно, про таких говорят: хоть кол на голове теши. И к программированию вы никакого отношения не имеете
> О, превентивный ad hominem от профессора. 😂
>>> Или Кену Томпсону тоже капитализм подгадил?
>> Он гадит вообще всем, даже тем, кто так не считает. Падение уровня образования - одно из проявлений
> Намекаете, что Кен Томпсона был тот самый "упавший" уровень образования?Код, написанный лично вами, или свободен.
> Код, написанный лично вамиА при чем тут код, написанный лично мной? Как он относится к теме обсуждения?
Прикольно
V4 действительно считалась потерянной
Более менее развитие шло с V5
Интересно, если найти самую-самую-самую первую программу на сишечке...
так тоже будет buffer-overflow?
Впечатлило два момента:1. Как просто было переписать на другой язык. Вот просто взяли и переписали следующую версию на сях. Не то что нынешние на раст. С другой стороны, есть подозрение, что переписывание на си давало бОльшую скорость написания кода по сравнению с ассемблером, что в случае с переходом с сей на раст не вариант (был бы не вариант даже при переходе на якобы более высокоуровнувую яву).
2. Первая сишная уязвимость появилась фактически при первом серьёзном использовании языка. Символично. Как выше пишут, преемственность поколений.
П.С. Сам растохейтер.
Хочешь прикол? Они переписывали на печатной машинке (телетайпе) и у них не было кнопки backspace по факту могли переписывать только всю строку заново при опечатке.
> Они переписывали на печатной машинке (телетайпе) и у них не было кнопки backspaceВсё то лучше чем смотреть на таблицу опкодов и вбивать хексом (а то и 1,0...) чтоб сделать сперва ассемблер, потом С и так далее, чтоб потом от потомков огрести какие все тупые были.
То ли дело у них, в их абстрактой клетке всё за них "нормальные" языки делают... и правильно делают! C таким менталитетом к прошлому их близко нельзя подпускать к более низкому уровню, зато какая блин гордость за "удобно" читаемый и "понятный" код на "нормальном языке", потому как mогут даже так:```
let x: () = ()=()=();```
> Всё то лучше чем смотреть на таблицу опкодов и вбивать хексом (а то и 1,0...) чтоб сделать сперва ассемблер, потом С и так далее,Конечно лучше
> чтоб потом от потомков огрести какие все тупые были.
Разве их кто-то называл тупыми?
Они как раз были умными: знали что пишут погано, но все равно делали.> C таким менталитетом к прошлому
Типа "нельзя критиковать Великих Программистов Прошлого!!!" ?
Даже если они писали однозначно плохой код, про который высказывался Дуглас Макилрой, цитаты которого уже пол темы мусолят.> mогут даже так:
> let x: () = ()=()=();Отличный код! Они явно вдохновлялись ++i == i++
>>Типа "нельзя критиковать Великих Программистов Прошлого!!!" ?Критикуя Великих Программистов вы показываете что не знаете за что их считают великими
>>Даже если они писали однозначно плохой код, про который высказывался Дуглас Макилрой, цитаты которого уже пол темы мусолят.В новости же всё объяснено, что "однозначно плохой" - это если бы был написан сейчас, а для начала 70-х это был разумный компромисс. Памяти было мало у компов, как не можете это понять, нельзя было писать большие программы.
С ассемблера на С переписать действительно (было) несложно. Особенно если знать ассемблер (а ведь есть и уровень ниже - машинных кодов, я с них и начинал - писал байтики в шестнадцатеричном редакторе). С - всего лишь следующая стадия макро-ассемблера. Обратное (фактически компиляция) гораздо сложнее, ибо нужно хорошо понимать как работает железо, то есть процессор, память, порты и тд. И чем дальше тем хуже: нынешние си погроммисты (кроме системщиков, как правило) не имеют представления о том как железо работает вообще. С одной стороны они пишут код для абстрактной машины (то есть переносимый), с другой - этот код может быть хоть и рабочий (с точки зрения процессора, не факт что периферии), но неоптимален.
> Вот просто взяли и переписали следующую версию на сях.Потому что сама ОС занимала всего "27 тысяч на языке Си + 30к ассемблера".
А su - 50 строк. Сравни это напр. с современным su-common.c - 1252 строки [1]
Это в 25 раз больше.В gnu core utils - 62833 строк чистого Си кода без хедеров и обвязок на шеле, перловке и прочем. В одном cksum.c - больше 1800 строк [2]
Просто программы были маленькие. Прибитые к конкретному железу.
И умели они примерно ничего.> переписывание на си давало бОльшую скорость написания кода по сравнению с ассемблером,
> что в случае с переходом с сей на растА разве раст ставит задачу ускорения написания кода?
С быстрым овнокодингом сишники и так справляются на отлично.
Если нужно "писать" быстро - то можно и ллмку запустить, качество вполне вероятно будет не хуже))
Там задача сделать код менее дырявым, с чем он прекрасно справляется.------------------------------------------------------------------------
[1] github.com/util-linux/util-linux/blob/master/login-utils/su-common.c
[2] github.com/coreutils/coreutils/blob/master/src/cksum.c
> Как просто было переписать на другой язык.только сперва понадобилось создать этот самый язык. Предназначенный именно для этого - быть тем же ассемблером но более удобочитаемым и требующим меньше колотить по клавишам.
До них ничего подобного не существовало - мертворожденные прожекты не в счет.
Ну и переписывали разумеется не ради самого переписывания, а потому что в v3 по сути работала одна-единственная программа, ставшая на тот момент уже ненужной. Чтобы система развивалась - проще оказалось переписать часть уже существующего кода, которую легче потом было бы дополнять.
> Не то что нынешние на раст.
потому что нескучный йезычок придумали в недрах мразилы, где проблему что кодить на нем, бегая от борова, получается адски долго - можно было завалить человеческим ресурсом. (но тут пришли _действительно_ эффективые менеджеры, и выкинули человеков вместе с созданными ими проблемами за борт с пароходика)
И внезапно - поддержка хрустокода оказалась сложнее (а не наоборот как у дедов). Потому что почти никто в этих нагромождениях закорючек не может разобраться. (А вот казалось бы - что может быть хуже c++ последних версий? Смогли!)
> Первая сишная уязвимость появилась фактически при первом серьёзном использовании языка.
тебе же ясно говорят - и это совершенно никого не колебло, вообще. На бесконечные проверки проверок не было просто ни мощностей ни времени. А то так и сидели бы как эти вон со своим ресдохом, где все безопастненько, только ничего не работает и не будет.
Большая часть увизгвимостей в общем-то существует только в воображении придумывателей цвешек и по сей день.
> Добавление проверок размера вводимых вручную данных рассматривалось как добавление лишнего кодаСами исконные диды, создатели языка, заложили эту идеологию разработки ПО. Это прекрасно. Можно добавлять в методичку по переходу на раст.
> Сами исконные диды, создатели языка, заложили эту идеологию разработки ПО. Это прекрасно."СИ мы пишем овнокод прям с самого создания" !
Отличный лозунг для отличного языка)))
Тогда падение в невероятных условиях не считалось значительной проблемой. Язык тут ни при чём, просто программировать тоже надо уметь. И программировать ещё не изобрели, когда придумали ассемблер.
Что значит "программировать "не придумали?
Они не могли написать "если пароль больше буфера goto error"?
Могли.Задумывались он о такой возможности?
Задумывались.
Дугласм сам пишет "nobody would ever want to input a 200-character line, say, so why bother writing
the extra code to catch it?"Им было просто плевать.
Это 1973 год.
Уже изобретены Паскаль, Smalltalk.
Алгол был еще в 60х, как Симула и Фортран.
> Это 1973 год.
> Уже изобретены Паскаль, Smalltalk.
> Алгол был еще в 60х, как Симула и Фортран.ну вперед, напиши ОС (или хотя бы попробуй переписать с ассемблера) на smalltalk.
>напиши ОС (или хотя бы попробуй переписать с ассемблера) на smalltalk.Да есть уже:
https://wiki.squeak.org/squeak/1762
Implement the bare minimum as native code (a mix of assembly and C), and then do everything else in Squeak.что-то видимо пошло не так, и без распроклятого нибизопастного си опять не получилось.
(но попытка конечно зачотная)
>что-то видимо пошло не так, и без распроклятого нибизопастного си опять не получилось.Да всё так. Без нынче модно проклинаемого C и asm низкоуровневые штуки не написать.
Как старый смаллтокер скажу, что все st vm (которые я видел, не считая экзотики поверх js) написаны исключительно на C / C++ и прекрасно себя чувствуют.Многие ярые пропагандисты rust похоже не понимают истинного назначения UB в С. Вот определили они умножение знаковых интов при переполнении и что? Кому это надо вообще? Вот в C это UB - явное указание программисту избегать таких ситуаций.
Опять же, откуда ты узнаешь, сколько байт ввели? Это надо счётчик для каждого символа, дополнительные проверки. В дополнение к 200 уже потерянным байтам. А вот каким образом в grub проверку пароля можно обойти нажав backspace несколько раз -- это другой вопрос. Это уже умысел.
нет, точно такой же ляп (только там символы удалялись а не добавлялись), просто та su еще и backspace не умела обрабатывать, ей было проще. Если ты бы умел кодить не на markdown и тот с ЫЫ - ты бы это и сам понял.
Если в следующей инкарнации я соберусь соорудить альтернативу опеннету, то ношение шапочек из фольги все же будет там приводить к перманентному бану.
> Опять же, откуда ты узнаешь, сколько байт ввели? Это надо счётчик для каждого символа, дополнительные проверки.Ты в код заглядывал?
там while((*q = getchar()) != '\n')
Они и так считывали ввод посимвольно.> А вот каким образом в grub проверку пароля можно обойти нажав backspace несколько раз -- это другой вопрос.
Это очень веселая и показательная история
opennet.ru/opennews/art.shtml?num=43536> Это уже умысел.
Не докажете)
>Это надо счётчик для каждого символаОдна строка - один счётчик.
>дополнительные проверкиИ? В чём проблема проверять ввод, как минимум, когда медленные пальци программиста вводят пароль? Вы боитесь неуспеть реализовать cve?
>А вот каким образом в grub проверку пароля можно обойти нажав backspace несколько раз -- это другой вопрос. Это уже умысел.Точно таким же. Как и в 1970-ые.
Ну правильно. Системы были мультизадачные и многопользовательские? А ты тут такты разбазариваешь. Тебя бы первого остракизму предали за растрату капиталистического имущества.
> По словам Дугласа, до появления червя Морриса в 1988 году мало кто обращал внимание на переполнения буферов. Добавление проверок размера вводимых вручную данных рассматривалось как добавление лишнего кода, а аварийное завершение при переполнении воспринималось как неуклюжая форма реагированияОткровенно говоря, лучше бы Дуглас Макилрой вообще ничего не комментировал. Ибо, помимо прочего, он рассказал о:
"Dennis once fed a couple-of-thousand-byte line on standard input to
everything in /bin. Crashes abounded, but so what? Wasn't a crash just
an ungraceful way for a program to say "I can't handle this"? Not
until the Morris worm (1988) did folks wake up to the real danger of
overflows."То есть еще в семидесятых корпоративные работники НАМЕРЕННО писали спустя рукава уязвимый, крашашийся г*код и выкатывали его в продакшн! А неладное начали подозревать только когда их ВНЕЗАПНО поимел червь Морриса.
Вот так вот один из тех самых "дидов" помножил на ноль россказни местных экспертов о прекрасном прошлом, когда легендарные деды (не то, что нынешние некомпетенты!) писали надежный код и создавали изящную архитектуру.
А в реальности-то, оказывается, дичь была еще похлеще, чем современное "тяп-ляп - и в продакшн". 😂
Зато сегодня они могут кряхтеть и бухтеть:
"воооот! смyзихлебы!! а вот в мое время! а вот мы!!"А тут выходит что СИ это язык от бракоделов для бракоделов)
Вызывает восхищение, что чел не просто дожил до 93 лет и способен говорить осмысленные вещи, но и помнит технические подробности о том, чем занимался лет 50 назад.
> но и помнит технические подробности...или он все преукрасил (выдумал) как любят делать люди в возрасте, вспоминая старое. По факту воспоминания так и работают примерно.
На тот момент важна была работоспособность в принципе
А не надежность , потому что надежность на неработающей системе не имеет смысла
> На тот момент важна была работоспособность в принципеА вот Дуглас говорит что:
"nobody would ever want to input a 200-character line, say, so why bother writing
the extra code to catch it?"То есть реальная причина была в "да и так сойдет". Но тебе, конечно, виднее, что там было важно на тот момент...
Это домыслы и натягивание совы
> А вот Дуглас говориДа малоли что он говорит. Дениса уже не спросить, но есть Кен Томпсон, а также Роб Пайк. Хотите назвать их бракоделами?
Вы так и не поняли нифига.Идея была в том, что прогу писали для выполнения конкретной функции.
Подразумевалось что на входе для получения нужного результата подают корректные входные данные.
Если данные не корректны - то пофиг что оно крашится, юзер ССЗБ.Писать 100500 проверок, валидаторов и тестов - не было на это ресурсов.
Даже одна проверка в цикле запросто роняла производительность на заметную величину, а если всё обложить проверками как нынче принято - то итоговая производительность запросто может рухнуть более чем в 2х, что тогда было не приемлемо и воспринималось: сделать тормозную прогу только для того чтобы пользователь получил красивое сообщение об ошибке.Так же не забывайте что писалось оно часто для себя и своего окружения, никаких какеров там не было - тупо ломать самого себя. Поэтому скрашилось - ну значит фигню вёл, попробуй ещё раз.
> Вы так и не поняли нифига.Да, только ты один тут владеешь сакральным знанием)
> Так же не забывайте что писалось оно часто для себя и своего окружения, никаких какеров там не было - тупо ломать самого себя. Поэтому скрашилось - ну значит фигню вёл, попробуй ещё раз.
Про червя Морриса он вспоминает просто так?
Или в контексте "мы писать дрмовый код, а потом нам надрали зад".
Не надо путать причину и следствие. Пока не появился червь морриса никто не задумывался об уязвимости. Грубо говоря, о заборах, дверях и замках стали задумываться только после того как появились воры. Есть действительно места, где нет воров - там не строят стен и заборов . Зачем? Да, я лично бывал и видел, такое в Средней азии в советское время было сплошь и рядом. Есть более современная расхожая байка про западного аудитора в Японии - он не мог объяснить что склад с запчастями должен запираться. Японцы не могли понять зачем - у них в фирме все равно как в семье. И никто никогда ничего не крал.
> Не надо путать причину и следствие. Пока не появился червь морриса никто не задумывался об уязвимостиТы с логикой дружишь? Наличие дыр в коле (причина) привела к появлению червя (следствие).
Червь Морриса был уже когда было написано много всего.Представь что у тебя был комп без сети, и ты лет 20 прогал на нём, иногда обменивась прогами с друзьями через дискеты - зачем тебе парится о безопасности какой то или красивых сообщениях об ошибках вместо крашей?
Притом 100% известно что лишние проверки тормозят выполенение программы от 5% до 80%, а комп у тебя и так кое как ворочается, и сложные рассчёты может сутками делать до результата.После червя стало по тихоньку доходить что особенности программ для которых они не написаны могут использовать другие и иногда для причинения вреда.
Но тема производительности всё ещё была очень актуальна, поэтому до повсеместного внедрения инета (читай года до 2000-2010) на это не сильно обращали внимание.Тот же ненавистный вечно дырявый зиродеями и зирокликами Flash player все не то что терпели а радостно ставили себе в систему потому что это был единственный(!) способ получать контент в виде масянь, игор и ютуба.
Не было просто другого способа это получить.
А флешплеер делал это всё потому что не тормозил так сильно - читай там не было 100500 проверок на каждый чих.
А теперь ответь на вопрос честно: ты бы предпочёл смотреть видосики с ютуба и играть в игры или сидеть без всего этого в безопасности?
>Притом 100% известно что лишние проверки тормозят выполенение программы от 5% до 80%Ага, ожидание ввода пароля, где скорость ограничена пальцами пользователя. Апологеты сишки не перестают врать.
>А теперь ответь на вопрос честно: ты бы предпочёл смотреть видосики с ютуба и играть в игры или сидеть без всего этого в безопасности?Знаете, если проприетарщики не слишком мешают, можно реализовать флеш плеер самостоятельно, но на этот раз правильно.
Я вам расписывал как и почему так писали в те времена.Зачем было добавлять проверки в su на предмет переполнения - было не понятно в те времена: код разбухал, а при неверном пароле юзер всёравно обламывался, те проверки были бесполезны.
Более того, возможно на тех компиляторах/архитектурах оно и не могло быть проэксплуатировано в виду их особенностей.
> Знаете, если проприетарщики не слишком мешают, можно реализовать флеш плеер самостоятельно, но на этот раз правильно.https://github.com/ruffle-rs/ruffle
вон на ржавчине переписали, так что оно то не работает то крашится, 5к иссуесов :)
У дидов то хотя бы игры и видео работали :))))
> мы писать дрмовый код, а потом нам надрали задПеревожу на современный лад: "если программисту нравится код, написанный им год назад, значит он прожил этот год зря". Сейчас же модно такое, даже в среде безопасных яв и прочих яваскриптов и питонов. Почему же вам так не нравится то же самое полвека назад?
И вам уже написали, что в те времена производительность меряли не гигагерцами, а герцами, и понаставленные во все места проверки привели бы к тормозам вплоть до невозможности использовать этот софт.
Поймите, мы не защищаем парадигму программирования без проверок на ошибки/уязвимости, мы объясняем необходимость её использования в те времена. Тогда это было настолько же актуально, как сейчас при программировании домашних страничек никто не пишет 5 строк тестов на каждую строку кода.
>в те времена производительность меряли не гигагерцами, а герцамиМегагерцами, а не герцами, врать не надо.
Простите, действительно соврал. Мне очень стыдно...Прув (вашей информации): https://retrocomputing.stackexchange.com/questions/6960/what...
> This link[https://ed-thelen.org/comp-hist/pdp-11.html] describes the PDP-11/20 as having a speed of 800 nanoseconds. That works out as 1.25 MHz.
> Because that speed is the speed of the memory, (which is tightly connected to the speed of the CPU), and because the databus is no wider than 16 bits, that means that the PDP-11 will at most execute one instruction per clock cycle. And that speed precludes other memory accesses, like DMA or instruction operands, use of the stack or immediate data, etc. So many instructions will take somewhere between 1 and 5 clock cycles.
> Подразумевалось что на входе для получения нужного результата подают корректные входные данные. Если данные не корректны - то пофиг что оно крашится, юзер ССЗБ.Ну да, а потом пришел червь Морриса, и они сделали удивленные глаза. И, главное, зачем-то полезли все исправлять.
> Даже одна проверка в цикле запросто роняла производительность на заметную величину
Очень актуально для su, который читает пароль из stdin. То ли дело бежать по char* в поисках нуля за O(n).
Твоя экспертиза - 10/10.
> Так же не забывайте что писалось оно часто для себя и своего окружения, никаких какеров там не было - тупо ломать самого себя
Что ты несешь? Unix - коммерческая ОСь.
> Вы так и не поняли нифига.
Сказал тот, кто промазал по всем пунктам. 😂
> Очень актуально для su, который читает пароль из stdin. То ли дело бежать по char* в поисках нуля за O(n).Вы бы изучили историю вопроса для начала.
В те времена юзали gets(buff); для чтения ввода, он не умеет в размер буфера.
https://www.geeksforgeeks.org/c/gets-in-c/Куда вы собрались прикручивать проверку? Внутрь библиотечной функции?
А зачем?
100 сивмволов пароль не корректный, пусть падает - нам не нужно красивое сообщение об ошибке - так тогда думали.
> Что ты несешь? Unix - коммерческая ОСь.Что это меняет?
Дурака который будет её ломать просто перестанут пускать в машинный зал на посте охраны.
> Вы бы изучили историю вопроса для начала.
> В те времена юзали gets(buff); для чтения ввода, он не умеет в размер буфера.Тоже самое можно и про вас сказать.
Какой нафиг gets(buff) если там прям в коде на 25й строке getchar()while((*q = getchar()) != '\n')
Они посимвольно считывали и прекрасно знали сколько символов было введено.
Да, я не смотрел в оригинальный код.
Знали, но не парились, потому что было не понятно чем это грозит, а падение проги от некорректного ввода было нормальным поведением.
> Да, я не смотрел в оригинальный код.Знаешь... я даже не знаю что сказать.
Зато успел в теме с умным видом наоставлять комментов про gets.Возможно ты просто эталонный коментатор этого сайта.
>Что ты несешь? Unix - коммерческая ОСь.Как бы, с версии 7 стала таковой. А до этого была, кроме самой Bell, учебной для университетов.
>Если данные не корректны - то пофиг что оно крашится, юзер ССЗБ.Опять сишники лгут. Оно не крашится, оно предоставляет уязвимость.
>то итоговая производительность запросто может рухнуть более чем в 2х, что тогда было не приемлемоПароль будет проверятся в два раза дольше - это так плохо. Давайте лучше сделаем уязвимость. И да, в то время производительность росла астрономическими темпами, пожертвуй даже десятикратно производительностью, и спустя несколько лет этого никто не заметит.
> Идея была в том, что прогу писали для выполнения конкретной функции. Подразумевалось что на входе для получения нужного результата подают корректные входные данные.То есть пароль в 200 символов - корректные данные, а 201 - уже нет?
> писалось оно часто для себя и своего окружения, никаких какеров там не было - тупо ломать самого себя. Поэтому скрашилось - ну значит фигню вёл, попробуй ещё раз.
Хм, а Дуглас Макилрой говорит:
"We did gradually learn that automatically
generated input lines--particularly lines of code--could be much longer than any person would write, so buffer overflows that actually happened gradually got fixed."То есть получилось "скрашилось - ну значит фигню в коде написал, попробуй написать снова по-человечески".
> Откровенно говоря, лучше бы Дуглас Макилрой вообще ничего не комментировал.Та не: он прокомментировал, стало чуть понятнее. Академия уже тогда говорила о том, что проверки размера буферов надо проделывать автоматически. Тогда это означало массивы врезанные в компилятор, и компилятор вставляющий проверки. Академия уже тогда предлагала автоматические способы оптимизировать и выкинуть часть проверок, чтобы тем не менее не допускать выхода за границы. Но поцреархи запиливают C, в котором нет массивов, и даже не задумываются о проверках. Как так?
Мне всегда это было непонятно, но теперь стало немного понятнее. Академия не могла предложить им объяснения почему это реально важно. Если бы академия тогда придумала бы червь Морриса и показала бы им, то они бы наверное задумались бы. Или если бы им показали бы эксплоит к этой уязвимости в su. Но они существовали в узком кругу людей, допущенных к компьютерам, которым в голову не приходило целенаправленно ломать поведение программ. Потом, когда компьютеры распространились шыре, и до клавиатур стали допускать случайных людей, вдруг появились черви и эксплоиты. Но до этого, они жили в мире где переполнения буферов действительно неважны. Они могли всё поломать, но при каком-то очень специальном и маловероятном стечении обстоятельств.
> А в реальности-то, оказывается, дичь была еще похлеще, чем современное "тяп-ляп - и в продакшн".
Угу. Но они б не создали Unix, если бы попытались бы дотянутся до уровня хотя бы современного "тяп-ляп и в продакшн". Сегодя, например, имея опыт раста, можно на C писать довольно надёжный код, просто потому что раст приучает к соблюдению довольно простых правил, которые снимают ряд проблем. Но в чтобы в 70-х допереть до этих правил надо было быть я не знаю кем.
Потребовалось 20 лет с тех пор, чтобы создать Ada, и ещё 20 лет, чтобы создать Rust. У поцреархов шансов не было взять и придумать всё это на ровном месте. Они могли бы попытаться изобрести что-то, набивая себе шишки, и пробуя разные подходы, но насколько бы они были бы быстрее индустрии, которой потребовалось 40 лет набивания шишек, чтобы дотумкать до раста?
> крашашийся г*код и выкатывали его в продакшн! А неладное начали подозревать
> только когда их ВНЕЗАПНО поимел червь Морриса.Они это и сейчас продолдают. Вон в rust - брякнуться в паник это вообще стандартная реакция программы. Зато безопасТно брякается, не то что всякое! Хотя CVE вон там рядом все равно почему-то получили. И чего это они?
Красивое.
Хейтеры не желают понимать очевидных вещей. Все версии Юникса это закрытые и проприетарные продукты. Исходные коды которого запрещалось свободно копировать и передавать. Юникс всегда был закрытым и коммерческим. Сейчас все Юниксы мертвы, кроме разве что Солариса.И только с появлением свободных клонов Юникса, таких как BSD-systems и GNU/Linux наши системы стали безопасными. Да, появляются время от времени уязвимости, но закрытие их стало обычной рутиной. На сегодня GNU/Linux и BSD-systems - по-факту, самые безопасные операционные системы. Да, именно копилефт и пермиссивка сделали код безопасным. Потому-что много людей могут посмотреть исходники и выявить уязвимости. В свободный код проблематично внедрить бэкдор.
> На сегодня GNU/Linux и BSD-systems - по-факту, самые безопасные операционные системы.Ну да, ну да.
"Продемонстрировано несколько способов обхода изоляции FreeBSD jail
На GitHub опубликован код 5 прототипов эксплоитов...
...в ходе исследования выявлено около 50 проблем
Большая часть проанализированного кода написана в 1990-х годах и давно не подвергалась аудиту." opennet.ru/opennews/art.shtml?num=64550"Диды писали" (с)
Прям эталон бизапасного кода! Тысячи глаз смотрели не туда! Может они просто смотрели шоколадными?
Ты явно передёргаваешь. На самом деле это означает что код совершенствуется, и становится безопаснее.Windows OS, macOS, проприетарные российские дистрибутивы - вот что реально опасно.
> Ты явно передёргаваешь. На самом деле это означает что код совершенствуется, и становится безопаснее.Не передергивает он. Поток дыреней, безостановочно льющийся более поувека, не очень совместим с термином "безопасность".
Эти системы, их технологии и походы разработки в плане безопасности двно и безвозвратно скомпрометированы.
мы хотя бы может знать что эти дыры исправлены, в отличии от проприетарщины, в которой могут умолчать о уязвимости
> мы хотя бы может знать что эти дыры исправлены, в отличии от
> проприетарщины, в которой могут умолчать о уязвимостиНу узнал ты что в коде была дыра с 90х и она наконец-то исправлена. Стало легче?
В ссупер свободном гню/ляляксе десять лет жил бекдор от спецслужб США.
А тыщщи глаз долбились в глаз (так себе каламбур, но для пятницы сойдет).
>> Не передергивает он. Поток дыреней, безостановочно льющийся более поувека, не очень совместим с термином "безопасность".
>> Эти системы, их технологии и походы разработки в плане безопасности двно и безвозвратно скомпрометированы.Правильно ли я понимаю? Все сводится к количеству реального сообщества программистов работающим над кодом? Т.е. чем оно больше, тем больше вероятность что код будет просмотрен большим количеством умных людей. Как в компаниях может быть много людей работающих над кодом, так и сообщество открытого кода может быть сформировано большое, ну и количество пользователей, тестировщиков, людей работающих с пользователями и т.д. Ну так дело то получается вовсе не в том открыт или закрыт код, а сколько у вас пользователей, разработчиков, тестировщиков, продавцов и какой бюджет? Ну и качество кооперации и знаний. А открытый код просто даёт возможность его копировать и расширять сообщество нужных людей для поддержки. Т.е. вопрос в том что юристы поддерживают для защиты подхода открытого кода. Вот периодически люди пишут тут про русские продукты которые по их мнению противоречат правилам придуманными американскими юристами. Если они из России и это поддерживают, то даже не осознают что предатели. Почему так на постсоветском пространстве сложилось не любить то что есть и стараться мыслить конструктивно? Я не знаю, это сложилось до моего рождения. Я вот сегодня написал человеку что лучше его живого преподавателя по программированию у него не было людей именно поэтому он стал настолько умничать что какого-то американского деда программиста стал боготворить, которого и в глаза не видел. А админ удалил - общество такое, время такое. Стесняшки. Ну сделаешь ты свой открытый код, получишь какое-то сообщество, а деньги не получишь. Сделаешь закрытый - получишь деньги, но не получишь сообщество что сделает менее безопасный код. Есть ещё нюанс в копировании - открытый код копируют используя наработки, закрытый - наблюдая за идеей или исследуя реверс-инженрингом. Потом смотри далее - получив деньги, получаешь ресурс на разработку, а это больше сообщество, лучше безопасность. Не получив деньги, можете получить их в виде контрибуции - чужая работа это те же деньги вложенные другим человеком. Каким тут боком открытый или закрытый код? О чем вы спорите? Знаете сколько вообще можно производных идей построить кроме open/close source?
В непроприетарном дырени около двух лет живут и никого это не смущает. Разницы в закрытом и открытом в плане безопасности нет совсем.
> В непроприетарном дырени около двух лет живут и никого это не смущает. Разницы в закрытом и открытом в плане безопасности нет совсем.А в проприетарном - 20 лет. И половину этого времени активно эксплуатируются, а исправлений нет, и не будет, как хозяин решит. И независимый аудит заказать нельзя. И исправления вносить нельзя. Нарушение лицензии, да и код закрыт.
Вот совсем-совсем никакой разницы. Главное, верить джентельменам на слово.
> Продемонстрировано несколько способов обхода изоляции FreeBSD jailТы пользуешься джейлами для того чтобы запускать юзверей под рутом? Если да, то тут для тебя в линуксе есть крутая вещь - capabilities процесса. Можешь спавнить сколько угодно http-серверов с портом 80 и 443, даже root не нужен, представляешь?
> В свободный код проблематично внедрить бэкдорЧто значит проблематично?
Просто "забываешь" проверить размер буфера и кто угодно может удаленно выполнить код.
Потом просто говоришь "ну забыл, с кем не бывает!"
И, ЧСХ, тут в комментариях к новости о очередной сишной дырени уровня "вылезли за буфер" почти всегда находится тот, кто на полном серьезе говорит "это закладка!".
Так хэйтеры именно поэтому и облизывают дырявую проприетарь. Нет, говорят, не нужны нам ваши любительские дилетантские поделки. С другой стороны, у виндоус тоже много поклонников.
> Хейтеры не желают понимать очевидных вещей. Все версии Юникса это закрытые и
> проприетарные продукты. Исходные коды которого запрещалось свободно копировать и передавать.настолько закрытые и настолько запрещалось - что исходник версии которая и работать-то толком еще не умела и существовала в паре десятков экземпляров - нашли в помойке _университета_. (а не в музее at&t каком-нибудь... впрочем в том музее стоит золотая статуя пятнадцатого по счету эффективного менеджера а не это вот все)
> Юникс всегда был закрытым и коммерческим. Сейчас все Юниксы мертвы, кроме
угу. Только раздавался в исходниках всем желающим. Причем универам он обходился совершенно забесплатно. Что и позволило появиться на свет bsd (тогда еще - вовсе не free) и потом на ее основе - тому из чего появился весь современный интернет (все еще тоже ни разу не free).
Жаль что современные университеты кроме снежинок и фрипластелинов похоже уже ничему научить не могут. Но вот уборщица - уборщица в этой Юте оказалась грамотная.
>> И только с появлением свободных клонов Юникса, таких как BSD-systems и GNU/Linux наши системы стали безопасными.Как давно мы обсуждали древнюю уязвимость, cve в утилите su? Кто его знает как реально было это написано? Вы вот знаете? Десятилетиями этот свободный код никому не нужен был?
> В свободный код проблематично внедрить бэкдор
- есть новость про Шайхулуд
- бинарный код вы не собираете, порой и автор который его пишет не собирает для репозитория того дистрибутива с которого вы берете и даже порой не создатели дистрибутива
- антивирусы используют хэш-коды и эврестический анализатор для выявления вредоноса, может как-то была изменена архитектура сообществом? Вот даже в Андроиде где вы даёте определенные разрешения и архитектура в этом плане получше не справляетсяВы думаете коммерческий код никто не анализирует?
Откопали копролитЪ.
Умудлились восстановить.
А там ̶а̶р̶м̶я̶н̶е̶ ̶в̶ ̶н̶а̶р̶д̶ы̶ ̶и̶г̶р̶а̶ю̶т̶ классическая сишная дыра!
Дыра для сегодняшнего времени. Для тех далёких времён, это не считалось дырой.
> Дыра для сегодняшнего времени. Для тех далёких времён, это не считалось дырой.Какого года червь Морриса?
На минуточку код по таким же "стандартам" писали и 80 и в 90.
Некоторые пишут и сейчас.Просто всем было плевать.
>> Дыра для сегодняшнего времени. Для тех далёких времён, это не считалось дырой.
> Какого года червь Морриса?
> На минуточку код по таким же "стандартам" писали и 80 и в
> 90.
> Некоторые пишут и сейчас.
> Просто всем было плевать.Отец Морриса, на секундочку, работал в АНБ.
Ты в глаза долбишься.> Какого года червь Морриса?
1988 года. А код UNIXv4 какого года? 1972-го.
Читай всю новость, прежде чем кидаться комментировать.
> Ты в глаза долбишься.Пф, ты сначала мозг включи, а потом оскорбляй.
>> Какого года червь Морриса?
> 1988 года. А код UNIXv4 какого года? 1972-го.А UNIX System V - 1983.
И что там?
А там та же самая СИшная дpыстня.
github.com/ngn999/UNIX-System-V/blob/182dea74d55cb447d1b0adba2d62b8f8cdcdd392/usr/source/s2/su.c#L4
> Пф, ты сначала мозг включи, а потом оскорбляй.Повторю: сначала новость полностью читай.
> По словам Дугласа, до появления червя Морриса в 1988 году мало кто обращал внимание на переполнения буферов.
>> По словам Дугласа, до появления червя Морриса в 1988 году мало кто обращал внимание на переполнения буферов.Так я и говорю.
Они знали что переполнение это плохо.
Им просто было на это плевать.
Неправильно. Они знали, что в тех условиях, в которых создавалось, это не имело значения. Никто ничего умышленно не ломал, люди просто решали свои практические задачи посредством компов, и в основном все они друг с другом были знакомы.Тебя попросят накидать на баше скрипт конвертации gif в avi - тоже будешь обкладывать его проверками со всех сторон; делать поиск подходящего набора утилит в системе и для каждой найденной утилиты писать свое решение; определять систему для вывода хинта; как их доустановить через конкретный пакетный менеджер? Или сконцентрируешься на решении задачи, которая по итогу займет одну строку?
> Тебя попросят накидать на баше скрипт конвертации gif в avi - тоже
> будешь обкладывать его проверками со всех сторон; делать поиск подходящего наборавот фу таким быть. Во-первых надо было конечно первым делом проверить что гиф это гиф (хотя бы через magic), а то вдруг это jpeg и он исполнит какой-нибудь вредоносный код!
Во-вторых надо отправить сэмплы куда-нибудь в облако - вдруг gif но не совсем.
Заодно и само изображение сохранить в бездонной бигдейте, вдруг там cp!Потом... потом надо вывести ошибка ашипка и повиснуть. Предварительно удалив файл потому что из-за пропущенной команды управление передалось в ветку которая вообще не должна была работать в этой версии.
Вот что я называю современным программированием, а не это вот ваше тяп-ляп!
> Тебя попросят накидать на баше скрипт конвертации gif в avi - тоже будешь обкладывать его проверками со всех сторон ?Нет! Проверки не нужны!
Всегда приятно сделать чашечку крепкого кофе и почитать новости.Критическая 0-day уязвимость в Chrome и libwebp, эксплуатируемая через изображения WebP
opennet.ru/opennews/art.shtml?num=59746
критическая уязвимость вызвана переполнением буфера в обработчике формата изображений
... в сети выявлен рабочий эксплоит, который уже применяется злоумышленниками для совершения атак (0-day).Уязвимость во FreeType, эксплуатируемая через TTF-шрифт и затрагивающая браузеры
opennet.ru/opennews/art.shtml?num=53922
... уязвимость уже активно эксплуатируется злоумышленниками (0-day). Проблема вызвана переполнением буфера в функции Load_SBit_Png, возникающим при обработке глифов с битовыми картами большого размера (указание в заголовке ширины или высоты больше 65535).Уязвимость во FreeType, позволяющая выполнить код при обработке шрифтов
opennet.ru/opennews/art.shtml?num=62875
Уязвимость вызвана переполнением буфера, возникающем при разборе субглифовых структурПрям как диды в этой новости завещали!
> Выявленную проблему прокомментировал 93-летний Дуглас Макилрой (Douglas McIlroy)Ух ты, дедуля ещё живой и комментирует! Классный чувак, долгой жизни ему!
Ознакомился с глупостями, начиная с первого комментатора. Заучите наизусть: использование программы не по назначению не означает ее уязвимости.
В каком министерстве можно получит точный номер и ОКВЭД назначения программы? Что делать с программами не внесёнными в реестр министерства?
Обратитесь к разработчикам. Определение назначения - их прерогатива. Только сначала лингвистические навыки подтяните, а то не поймут и не ответят.
О, чела который думает, что убирание логина в root по ssh и оставления дырки обратно в виле sudo делает систему безопаснее, порвало. Вытащи наружу su через 'ncat -k -e su', мы тебя попинтестим всем опеннетом.
извини, но su использовалась по назначению - для получения рутовых прав. И если она это делала даже если ты не знаешь пароля рута - значит это таки уязвимость.Хотя и чисто теоретическая - кому был тот пароль нужен, мог его у Кена просто спросить.
> Код ядра UNIXv4 был написан Кеном Томпсоном,
> а драйверов - Деннисом Ритчи.
> Код содержал уязвимость, приводящую к переполнению буфераЕсли это не Настоящие™ Сишники™, то кто тогда достоен этого звания?!
А существуют ли Настоящие™ Сишники™ вообще???
"Настоящим" без разницы, на каком языке создавать выдающиеся исходники. Собственно, это понятно из текста новости.
"Настоящим" без разницы, на каком языке создавать выдающиеся исходники.Настоящие сишники пишут на паскале.
На самом деле, любая защита портит жизнь миллионам приличных и законопослушных людей, чтобы защититься от единиц мерзавец. Так и с замечательным языком Си случилось. Однако, если бы шли по коммунистическому пути, то мерзавцев бы практически не осталось, и не нужно было бы городить огород с защитой от переполнения буфера и прочего, и не нужен был бы Раст, который пропихивают вонючие капиталисты. То есть изначально человечество идёт не туда, растрачивая силы во имя зла, то есть империализма, а не добра, то есть общества (коммунизма).
Всё так. Были времена, когда хакеры решали научно-технические задачи, стоявшие перед обществом, и решали их с вниманием к потребляемым ресурсам.
Но пришло время вредителей, лишь называющихся хакерами, но хакерские принципы не уважающими. Которые прикрываясь благими намерениями, творят черное дело: ломают, а не строют, вносят разлад и недоверие среди людей.
И вместо того, чтобы вредителей отловить и обезвредить, общество доверило рыночку их встроить в себя. Очередной бизнес на крови: одной рукой ломаем, другой - строим, разницу - в карман.
Дошло до того, что уже код писать некому, одни лишь форумные болтуны наваливают экспертизу на вентилятор. И как дети радуются "дыреням" в коде, вместо того чтобы посыпать голову пеплом и исправлять *свои* недоработки. Но кодить они не умеют, зато умеют выписывать другим рецепты биологически-активных безопасных языковых добавок, за долю от спонсоров. И пусть изучает эти NT кто-нибудь другой и переписывает на них всё на свете. Они свою работу сделали: нараздавали бесполезных и вредных советов, продали ничего не подозревающему обществу с высоты своей к$ксп$ртизы очередной товар - волшебную пилюлю от всех болезней.
Кошелек, брошенный на дороге, беззащитен. Кошелек в кармане определенно более защищен. Замена обсуждения, хорош ли кошелек, обсуждением, нужно ли к каждому кошельку присовокупить капкан, не имеет смысла.
Но никто не может дать гарантию, что мерзавцы не появятся извне планеты.
> На самом деле, любая защита портит жизнь миллионам приличных и законопослушных людей, чтобы защититься от единиц мерзавец.Давай отменим законы запрещающие убивать, грабить и ездить зайцев в автобусе!
> Так и с замечательным языком Си случилось.
В СИ есть какая-то защита?
Из заSHITы в нем только SHIT.> Однако, если бы шли по коммунистическому пути, то
В стране было бы много лагерей в которые в вагонах для скота свозили неугодных со всей необъятной))
> мерзавцев бы практически не осталось,
Конечно. У власти не могут быть все. А только партийные функционеры и номенклатура!
> добра, то есть общества (коммунизма).
А кто не согласен, тому добрый НКВДшник пустит пулю в затылок!
Это не совсем правда. Конкретно в данном случае это именно баг в софте, а не просто злой хакер. Потому что систему ломал бы даже добропорядочный пользователь с паролем в 250 символов (пароль рута должен же быть безопасным). То, что вы описали про хакера (классический "хакер в столовой"), - это, например, timing-based атаки на функции проверки пароля, или современные мелтдауны.
Нет, ну а что же. Остались ещё социалистические страны. Социализм - это же переходный период на пути к коммунизму, верно? Значит они идут к коммунизму, так? И посмотрите на них. Северная Корея, Куба.. Кстати, что там с Кубой? Про неё давно ничего даже не слышно. Так и сидят без света? А Куба вообще ещё существует? Ляпота. Вот и можно себе представить, как будет выглядеть этот самый коммунизм, когда социализм выглядит сегодня вот так.
Коммунизм это когда живут в коммунах, все общее, средства производства, женщины и дети.
А обои у них неплохие были.
В 73 году там скорее всего только консоль была. А десктоп с обоями.
а не десктоп
Терминал это все лучшем случае, если не перфокарты.
> Позднее код UNIXv4 был приведён в порядок и опубликован на GitHubПо ссылке Equilateral-AI с соавтором Claude Opus 4.5 свалил вместе V4, V5 и V6 без пояснений, что где. И сгенерировал readme с советом переписать на расте.
Option B: Modern Reimplementation
- Implement in modern C/Rust
Мы вообще-то исторический артефакт обсуждаем. А не проблему, как к "Джоконде" пририсовать бульдозер.
Я об этом и говорю, можно оставить ссылку на http://squoze.net/UNIX/v4/README, а нейрослоп удалить.Ещё из той репы: https://github.com/Equilateral-AI/UnixV4-Resurrection/tree/m...
Нейронка считает, что в пустом каталоге у неё лежит ядро MicroUnix для виртуальной машины Rust VMM, которая состоит из println!("Hello, world!")*. И что это имеет отношение к истории Unix.* https://github.com/rust-vmm/rust-vmm/blob/main/rust-vmm/src/...
> Rust VMM, которая состоит из printlnЛадно, это моя ошибка. Но в ссылке из статьи странности продолжаются.
> Current Status
> Terminal UI: Complete - Retro CRT-style terminal with green phosphor aesthetics
> PDP-11 Emulator: Not yet integrated
> Unix V5 Boot: Pending emulator integration
> https://github.com/Equilateral-AI/UnixV4-Resurrection/tree/m...
Наконец-то фанаты философии UNIX смогут пользоваться настоящим Юниксом, написанным академиками!
>Данная утилита включала менее 50 строк кода, устанавливалась с флагом setuid-root и позволяла запустить /bin/sh с правами root при вводе правильного пароля. Код содержал уязвимость, приводящую к переполнению буфера из-за копирования вводимого пользователем пароля в фиксированный 100-символьный массив без проверки размера вводимых данных.Это просто гимн качеству кода на си. Упаковать уязвимость в 50 строк кода - это надо уметь.
Ну хорош умничать с линтерами, статическими анализаторами, форматерами. Раньше этого не было
А для этого надо язык не на коленке сочинять, как это сделал Ритчи.
Для того чтобы создать rust вы почитайте количество технологий которые нужно было создать для этого. А ещё должен быть накопленный опыт чтобы вообще теоретически его создать. Кто-то должен этот опыт систематизировать и обдумать в новый язык программирования. А ещё сюда добавьте рекламу и финансовые вливания в проекты на нем. Вот тот же haskell чем-то на него похож, он был создан ранее, но почему-то не пользовался популярностью. Есть допустим такие языки как Пролог, Лисп которые имеют совсем иной подход к программированию. На них тоже много чего интересного и без ошибок можно сделать, но не популярны - сложные считаются.
А ещё можно было бы написать
var buf: string[100];
и не париться с созданием какого-то нового язычка.
Только один даже этот перл кода, побуждает сходить за пивом:/* To convert to msec, must divide a 64b quantity by 10000. This is actually done
by dividing the 96b quantity 0'time by 10000, producing 64b of quotient, the
high 32b of which are discarded. This can probably be done by a clever multiply...
*/quo = htod = 0;
for (i = 0; i < 64; i++) { /* 64b quo */
htod = (htod << 1) | ((tod[1] >> 31) & 1); /* shift divd */
tod[1] = (tod[1] << 1) | ((tod[0] >> 31) & 1);
tod[0] = tod[0] << 1;
quo = quo << 1; /* shift quo */
if (htod >= 10000) { /* divd work? */
htod = htod - 10000; /* subtract */
quo = quo | 1; /* set quo bit */
}
}
return quo;
}void sim_os_sleep (unsigned int sec)
{
sleep (sec);
return;
}Явно студенты со здоровым чувством юмора были !
Пионеры IT )
Стиль убогий. Но где вы хороший стиль программирования на С видели? Разве что в документации Borland и в тех проектах, авторы которых восприняли эту эстетику.
Так раньше пиво было полезнее, гораздо полезнее, чем сейчас.
А ничего что математический сопроцессор появился после написания этого кода?
Я не понял, а лицензия то какая на этот код? AT&T разрешение дало на публикацию? Так-то ведь он проприетарный.
" Unix в Bell Labs "
Что это означает в контексте вопроса?
Тоже задался этим вопросом. Но надо помнить, что исходный код уже публиковался Opensolaris под открытой лицензией, по сути System V.
там интересно, что getchar возвращает 0 а не EOF если конец ввода или ошибка.
в man того времени это даже задокументировали как BUG.
и с типами возвращамых значений не парились.
вообщем дидам было тяжело, а прогресс виден.
>> Выявленную проблему (с утилитой su) прокомментировал 93-летний Дуглас Макилрой (Douglas McIlroy), входивший в команду изначальных разработчиков Unix в Bell Labs, предложивший концепцию неименованных каналов и создавший такие утилиты, как echo, spell, diff, sort, join и tr.Да, жаль что много лет назад чувак входивший в команду разработчиков Bell Labs (которая сотрудничала с военными) потеряла носитель с такой важной уязвимостью. Это ж сколько устройств могло быть благодаря этому не взломано?
Интересно они часто там чет теряют касательно обнаруженных уязвимостей?
Вот видите, человек всю жизнь писал на С, и в 93 года у него всё ещё хорошая память и речь. А если бы после написания каждых 10 строчек кода трясся как бы не сделать CVE или писал бы на Rust'е, то ...
Отсюда вывод: не берите ничего сложного в голову.
Хорошая память и речь зависит от тренировки ума, еды и сна, наследственности, условий жизни. Не стоит сравнивать - у каждого совсем по другому, но это не значит что других людей нужно обесценивать. Ну вот к чему эти натуженные перепирательства между теми кто программирует на С и rust? Зачем?
Предлагаешь пить пивас и пялится в телек?
Хорошая речь м память зависит от начитанности.
> человек всю жизнь писал на СДжобс тоже всю жизнь писал на Си... До 56 лет дожил.
Джобс ничего не писал. Ни на си, ни на *ососи. У него для этого был Возняк.
Джобс классический пример гуманитария. Вместо веры в доказательную медицину, лечился нетрадиционной медициной.
>>Интересно они часто там чет теряют касательно обнаруженных уязвимостей?Теряют часто, но зато уборку делают редко
А вот в Майкрософт cve никто не ищет там одни блобы.