https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html Работа хостинга свободных проектов savannah.gnu.org (http://savannah.gnu.org/), в рамках которого развиваются многие GNU-инструменты, временно приостановлена. Судя по опубликованному на сайте сообщению, сервер был взломан через подстановку SQL-запроса в web-сервисе Savane2, в результате чего злоумышленнику удалось получить доступ к базе аккаунтов, содержащей шифрованные пароли всех пользователей хостинга. Используя данную базу, злоумышленнику удалось подобрать некоторые пароли и использовать из для доступа к размещенным на хостинге проектам.<br><br><br><br>В настоящее время ведется работа по восстановлению содержимого сервера из резервной копии, созданной 23 ноября. Все изменения, добавленные в репозитории исходных текстов после 23 ноября потребуют ручного восстановления. Статус восстановления можно посмотреть в микроблоге fsfstatus (http://identi.ca/group/fsfstatus).<br><br><br><br>Одновременно неудача постигла сервер lists.gnu.org, на котором в RAID-массиве оказались (http://identi.ca/notice/59494378...<br><br>URL: http://lwn.net https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#35 Thu, 02 Dec 2010 03:52:59 GMT Вообще-то у ВАЗа был свой крупный завод станков.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#34 Wed, 01 Dec 2010 16:13:50 GMT &gt; пс: о да о безопасности должен думать проггер бля - а шо человек пишуший API к субд не проггер ? и кто виноват ?<br><br>В реальности же виноват лишь один дурак, которому указали Путь, следуя которым он избавится от указанных проблем как класса. Тогда как он вместо того, чтобы заняться делом, все продолжает с маниакальной настойчивостью искать виноватых. 'Ищите ищите - должон быть' (c) фильм.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#33 Wed, 01 Dec 2010 14:31:49 GMT &gt;&gt; пхп открой уважаемый<br>&gt;&gt; если ты знаешь что такое SQl injection это не означает что все<br>&gt;&gt; знают<br>&gt;&gt; пс: все уязвимости появились после появления этого долбанного пхп )))<br>&gt; В PHP сто лет в обед как есть PDO с вменяемой поддержкой<br>&gt; prepared statements. Точно так же как в Perl есть DBI или<br>&gt; в Ruby или Python свои аналогичные обвязки. Если кто-то их не<br>&gt; использует - это уже сугубо его личные сексуальные трудности и язык<br>&gt; здесь бессилен. Любой.<br><br>пр препейред слышали проценты - ибо пхпешники такой тип прогеров (в основном начинающих) которым - лиш бы работало<br><br>и плюс виноваты разработчики субд - нахрена допустим в sql разрешать не закрытый многострочный комент ? или ваще нахрена они там сдались коментарии ?<br><br>виноваты разработчики API к субд - нахрена создавать небезопасные функции ?<br><br>пс: о да о безопасности должен думать проггер бля - а шо человек пишуший API к субд не проггер ? и кто виноват ?<br><br><br><br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#32 Wed, 01 Dec 2010 14:26:42 GMT виноваты кривые руки не производителей ВАЗа а производителей станков<br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#31 Wed, 01 Dec 2010 11:13:50 GMT То-то у меня кое-какие пакеты с savannah.gnu.org с первого раза не скачались! <br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#30 Wed, 01 Dec 2010 11:02:28 GMT &gt;а то что вы даже понятия не имеете как устроена память - что за это Ричи надо винить ?<br><br>Да ну? Просветите меня, профессор, почему же это переполнение буфера вообще невозможно отследить без специальной аппаратной поддержки, если программа написана на высокоуровневом языке программирования? А то мы, печники, по-своему мыслим.<br><br>Большинство прикладных программ на низком уровне с памятью не работают. Переполнение буфера чаще всего возникает из-за отсутствия проверки границ массивов, которая могла бы быть реализована на уровне компилятора, но ее не реализовали в C для выигрыша в производительности. Арифметика указателей осложняет проверку, но можно было бы, например, усложнить указатели, сделав их не обычными числами, а специальными конструкциями, чтобы указывать компилятору, в каких пределах они могут изменяться. Всего этого в языке C нет, даже опционально (как в Фортране, например), и, скорее всего, никогда не будет.<br><br>А поскольку большинство программ написано на C, мы с этим будем еще долго жить.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#29 Wed, 01 Dec 2010 10:47:56 GMT Конечно :-) Кривыми руками везде можно накосячить.<br>Это позволяет любое средство обращения к БД через SQL.<br><br>Я просто хотел сказать, что строить запрос в коде руками плохо :-) И есть куча средств, чтобы этого не делать. И это вроде всем понятно и известно. Всегда будут находится недокументированные возможности.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#28 Wed, 01 Dec 2010 08:38:10 GMT При желании даже JDBC позволяет выполнять SQL запрос, который можно перед этим выстроить без параметров в строке :)<br>Так что тут тоже всё возможно.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/72957.html#27 Wed, 01 Dec 2010 08:13:33 GMT &gt; пхп открой уважаемый<br>&gt; если ты знаешь что такое SQl injection это не означает что все<br>&gt; знают<br>&gt; пс: все уязвимости появились после появления этого долбанного пхп )))<br><br>В PHP сто лет в обед как есть PDO с вменяемой поддержкой prepared statements. Точно так же как в Perl есть DBI или в Ruby или Python свои аналогичные обвязки. Если кто-то их не использует - это уже сугубо его личные сексуальные трудности и язык здесь бессилен. Любой.<br>