LINUX.ORG.RU

Обнаружены новые уязвимости в bash

 , shellshock


3

3

Не успело сообщество отойти от уязвимостей ShellShock, как сотрудник Red Hat Флориан Ваймер опубликовал информацию о новых. Уязвимости CVE-2014-7186 и CVE-2014-7187, возникающие из-за некорректной обработки операций с памятью при разборе выражений, перечёркивают все прошлые усилия по закрытию ShellShock и позволяют удалённо выполнять любые команды.

Протестировать наличие проблем CVE-2014-7186 и CVE-2014-7187 можно при помощи выражений:

   bash -c "true $(printf '</dev/null
   if [ $? != 0 ]; then
      echo -e "Vulnerable to CVE-2014-7186"
   fi

   bash -c "`for i in {1..200}; do echo -n "for x$i in; do :;"; done; for i in {1..200}; do echo -n "done;";done`" 2>/dev/null
   if [ $? != 0 ]; then
      echo -e "Vulnerable to CVE-2014-7187"
   fi

Пользователи FreeBSD и NetBSD вне опасности, поскольку тамошние мейнтейнеры решили пожертвовать обратной совместимостью и полностью отключили эту часть функционала bash.

Ещё две уязвимости CVE-2014-6277 и CVE-2014-6278 обнаружил сотрудник Google Михаил Залевский, но отказался публиковать подробности до внесения исправлений в bash. Учитывая, что для разбора кода функций в bash применяется большой универсальный пласт кода, который потенциально может предоставлять множество различных векторов для атак, так как данный код написан без оглядки на обработку данных, поступающих извне, неизвестно сколько ещё уязвимостей нас ожидает впереди.

Кроме того, можно отметить статью разработчиков Perl, в которой описываются пути проявления уязвимости в perl-скриптах, запускаемых в системах, в которых bash используется как /bin/sh и $SHELL. Проблемы могут проявляться в скриптах, в которых используется вызовы system и exec без разделения аргументов или при открытии потока через open с перенаправлением вывода. Проблемы не специфичны для Perl и проявляются в любых других языках, позволяющих выполнять команды с использованием командной оболочки.

Также опубликован дополнительный анализ возможных серверных систем, в которых возможно проведение атаки. Кроме упоминавшихся ранее атак на DHCP-клиенты, CGI-скрипты и ssh-аккаунты для Git/Subversion, в обзоре утверждается о вероятном проявлении проблемы в OpenVPN (при соединении с сервером злоумышленника), Exim, qmail, procmail, Mailfilter, SER, Phusion Passenger, Radius-серверах и службах Inetd (например, tcpserver). Не подвержены проблеме Postfix, stunnel, OpenBSD inetd и xinetd.

Для комплексной проверки систем на подверженность атакам Shellshock подготовлен универсальный скрипт.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: ymn (всего исправлений: 1)

Ответ на: комментарий от PerdunJamesBond

Эмм, так у меня как раз и стоит 4.3.9-2 и все равно показывает, что уязвим к CVE-2014-7186 (redir_stack bug). Он у вас после установки еще и патченный из дебиановских реп апдейт-секьюрити?

CoolAller
()
Ответ на: комментарий от AS

Ты не путай код на языке высокого уровня, который должен быть удобно читаемый и хорошо тиражируемый, с просессоро-ориентироманными инструкциями.

Высокоуровневый код не обязан быть подобием жабы - жаба у нас ещё есть. И ассемблерные вставки тоже нужны - без них даже на плюсы не обходятся, начинаешь пытаться скомпилить код под линукс и тут вылазит что, без переписывания куска, нельзя.

Я вообще не понял, откуда началось это сравнение и кому в голову пришло. Я с goto начал читать. :-)

А гото откуда пришло в массы и где показало свою няшность? Персональные аппараты с башем, они стали доступны не так давно, а до этого было да лампочки что баш в чём-то неудобнее а учить в нём дофига.

Но сам синтаксис у bash на голову выше, как как разработан с учётом уже существующего опыта, в том числе и бейсика.

Интересно, как это люди фанатеющие от С/С++ могли взять и придумать хороший синтаксис? У них, как в анектоде о мужике, который не мог собрать из деталей швейную машинку и в итоге упорно получалось более привычное изделие (в анекдоте был АК). И потом, нужна же совместимость с кривыми альфаверсиями синтаксисов, чтобы народ не переучивался!

Говорить, что бейсик лучше, так как у него goto есть и структура кода хорошая - это бред.

От гото польза при правильном применении и, в отличии от аппаратнозависимых типов переменных в Си, им пользоваться никто не заставляет , а структура кода в бейсике - так ведь понятная и без перлообразной каши. А то, что МС может испортить неплохую вещь а потом на неё забить, думаю объяснять не надо. Уменьшение количества строк в интерпретируемом коде было актуально во времена дискет - чтение каждой строки = запуск моторов дисковода и шаркание читалкой. Сразу загрузить весь файл в память и потом выполнять нельзя: а вдруг при выполнении первой строки оператор отредактирует вторую. При _таком_ применении ЯП, гото конечно вносит сложности, но можно же обойтись директивой типа $$goto_on после которой и гото действует и код заглатывается интерпретатором большими кусками а не построчно. Но раз баш не улучшают, то надо плодить велосипеды.

Napilnik ★★★★★
()
Ответ на: комментарий от init_6

Нет мы начали с того что ты начал тыкать в сторону ext2 1993го года выпуска с позиции NTFS Version 3.1 2001го года… И почему-то тебе не понравилось что в том же 1993м был NTFS Version 1.0 который из Windows NT 3.1 и который там никто не использовал потому что он никому там не был нужен и потому-что жрали в те времена FAT и это было нормой.

Где я говорил про ext2? С какой позиции? Ты что-то там много домысливаешь за меня.
Суть в том что в Windows и Mac OS X давно из коробки 255 UTF-16 знаков на имя файла, а в GNU/Linux всё ещё этого нет.
Ладно не буду больше трогать твой хрупкий мирок.

Касаемо багтрекера я уже кидал багтрекер Etersoft, оттуда видно что там не всё просто (особенно с ext4). На кернел.орг я нашёл только это. Будет желание и время попробую сам создать тикет (вряд ли это поможет, но посмотрим), так как хочу на сервере держать файлы длинных имён без костылей и на надёжной ФС, а сейчас меня пока только на кококо на лоре хватает.

EvilFox ★★
()
Ответ на: комментарий от EvilFox

Суть в том что в Windows и Mac OS X давно из коробки 255 UTF-16 знаков на имя файла, а в GNU/Linux всё ещё этого нет.

Суть в том, что в GNU/Linux есть пакетные менеджеры и снапшоты уже только это - неосуществимая мечта убогих и обделенных вендузятников которых кормят обещаниями что когда то это будет и у них. А главные последствия в том, что GNU/Linux доминирует в top500 на мобильном рынке и в самых разнообразных встроенных устройствах а сраная венда всё еще занимает свою нишу только потому что покупает и подкупает производителей железа.

Касаемо багтрекера я уже кидал багтрекер Etersoft

Этеркто? На кой хрен мне всрался багтрекер форка wine?

оттуда видно что там не всё просто (особенно с ext4).

Оттуда видно что они не имеет никакого отношения к ядру Linux.

Кроме того я открою тебе страшную тайну - в мире GNU/Linux все фичи делаются либо непосредственно руками тех кто в них заинтерисован либо руками профессионалов которым платят те кто заинтерисован в определенных фичах…

Так вот внимание вопрос - почему с 2000х годов всем в GNU/Linux попросту насрать на совместимость со сраной говновендой? И ответ на этот вопрос этот касается вовсе не количества пользователей в ОСях… Ответ в том кто ближе к стандартам. И под стандартами я понимаю не стандарты сраной говновенды, на которые даже она сама ложит болт, а стандарты POSIX, ISO, DIN и т.д.

init_6 ★★★★★
()
Ответ на: комментарий от ii343hbka

Я не знаю как у тебя, а я сделал просто: вот отсюда взял от бубенты 14.04 вот этот пакет с башем собранным статически под armhf, выдернул из него бинарь, воткнул его в свой планшетик с андроном вместо старого баша и все работает как куранты.
зы: баш у меня отдельно от бузибокса, в бузибоксе другой шелл, аш кажись.. да и не встречал я баш в бузибоксах ни разу.

Indexator ★★★
()
Ответ на: комментарий от Napilnik

Высокоуровневый код не обязан быть подобием жабы - жаба у нас ещё есть

А при чём тут жаба ? Или, вернее, только жаба.

И ассемблерные вставки тоже нужны

Они нужны в очень узкоспециализированном сегменте: в районе работы с устройствами. Это не такая большая часть ПО.

А гото откуда пришло в массы

Из машинного языка, очевидно.

и где показало свою няшность ?

Нигде. Это только средство запутать код.

Интересно, как это люди фанатеющие от С/С++ могли взять и придумать хороший синтаксис ?

Я, кстати, не утверждал, что он хороший. Просто хуже Basic, на данный момент, нет уже ничего. Да, он мог быть где-то нужен. На калькуляторе, к примеру. Но на чём-то более серьёзном это уже лишнее.

AS ★★★★★
()
Ответ на: комментарий от init_6

Этеркто ? На кой хрен мне всрался багтрекер форка wine ?

Ты немножко несовсем в курсе, где можно найти их патчи, и вообще, что им приходится делать, чтобы их форк работал. Кстати, в оригинальный wine тоже попадает от них кое-что. Можешь зайти на winehq.org и поискать там etersoft.ru. Ради общего развития.

AS ★★★★★
()
Ответ на: комментарий от Napilnik

У них, как в анектоде о мужике, который не мог собрать из деталей швейную машинку и в итоге упорно получалось более привычное изделие (в анекдоте был АК).

Время ушло, люди уходят, обстоятельства изменились - и анекдот переиначили полностью... (

yyk ★★★★★
()
Ответ на: комментарий от yyk

и анекдот переиначили полностью... (

Да они уж, наверное, и не знают трактор Беларусь...

AS ★★★★★
()
Ответ на: комментарий от Napilnik

Лепить тут функции - коряво

вот это попробуй:

#!/bin/bash

echo "код №1"

if false; then
{
	echo "код №2"
}
fi

Для нубов, напоминаю, что метки типа :1, :2, :10, :20 отлично работают и в других языках, просто потому что они удобны

удобнее использовать метки с символическими именами. Метка :1 требует ещё и комментарий.

Где грибов таких забористых достал? Это в бейсике то нет блоков? Да они там по умолчанию. Интерпретатор выполнял код по строкам, в которые можно было запихнуть столько кода, сколько влезет. И чем больше операторов в строке, тем в среднем быстрее выполнялась программа.

это уже более свежие бейсики. В первобейсике в одной строке был только _один_ оператор. Потом сделали бейсики с длинными строками, и без обязательных номеров строки.

Если им особо не пользоваться, то и не нужно, вот только на бейсике можно было и игру сваять, а на баше это мазохизм.

не вижу разницы. В bash'е это даже проще будет.

Смотри выше - для экономии кучи времени при изменении процесса сборки кода, в котором что-то идёт не так. Там много чего надо, не только гото.

смотри выше, есть блоки, если «функции корявые у меня».

Учи матчасть чтобы не тупить даже на своих примерах. Велик - он лёгкий

это ты тупишь. Дело не в весе, а в том, что у автобуса есть карданный вал. И ему цепь тупо не нужна. Как goto в bash'е.

emulek
()
Ответ на: комментарий от Napilnik

Так что и для этой задачи в нём есть решение, просто про запас: операторы POKE и PEEK.

к сожалению, это сработает только в однозадачной среде. В bash команды запускаются в отдельном процессе, потому POKE/PEEK не имеют смысла.

emulek
()
Ответ на: комментарий от AS

И что ?

ну по его логике выходит, что «баш говно, т.к. там нет GOTO/POKE/PEEK».

emulek
()
Ответ на: комментарий от Napilnik

И можно через них реализовать много чего а потом запустить программу в машинных кодах. В одной игре так был реализован

забудь. Это сработает только в MS-DOS. Даже в Windows95 это не взлетит.

Я конечно рад за тебя, что ты ещё не умер, несмотря на преклонный опыт, но таки что ты делал последние 30 лет? MS-DOS давно уже никто не юзает. Как и бейсик.

emulek
()
Ответ на: комментарий от init_6

А длина имен файлов…

а длинна имени файлов в WinXP и новее(для совместимости) не более 265 символов(точнее байтов, ещё точнее ­— октетов) ЕМНИП. Точнее можно посмотреть в header'ах, которые доступны после установки MS Visual Studio с MSVC. Или это недостоверный источник?

Т.ч. пофиг, сколько символов умеет маздайная ФС, сам маздай более 265и не умеет.

Это чуть больше, чем в Linux, потому можно создать архив с файлами с именем из 260 байт, которые не распакуются в Linux.

С другой стороны, GNU tar умеет имена файлов _любой_ длинны. Старый формат имел ограничение 100 байтов, в новом это исправили, и длинна имени _не ограничена_, хоть гигабайт.

emulek
()
Ответ на: комментарий от emulek

Т.ч. пофиг, сколько символов умеет маздайная ФС, сам маздай более 265и не умеет.

Нет, тут проблема есть. Именно в разнице байт/символ. Если у тебя кодировка koi8, то ты проблему не увидишь, но вот если ты на utf8 перейдёшь в Linux, то файл с русским названием из 200 символов ты к себе уже не скопируешь из Windows.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Ты немножко несовсем в курсе, где можно найти их патчи, и вообще, что им приходится делать, чтобы их форк работал.

Оригинальный wine это не полный crossover от codeweavers. И вот из crossover в wine попадает всяко больше чем из этэрсофта.

Кстати, в оригинальный wine тоже попадает от них кое-что. Можешь зайти на winehq.org и поискать там etersoft.ru. Ради общего развития.

В ядро linux попадают даже патчи из микрасофта и что из этого? Если судить по вкладу фирм так всё равно linux пишет red-hat.

init_6 ★★★★★
()
Ответ на: комментарий от emulek

Или это недостоверный источник?

Лично мне по барабану сколько оно умеет или не умеет… Я ни одного раза не сталкивался с такими ограничениями ФС в GNU/Linux которые бы сделали мою жизнь не комфортной. И при этом я постоянно сталкиваюсь с такими дикими граблями в сраной венде если приходится с ней работать. Элементарная задача записать iso на болванку. В linux это одна консольная команда и оно будет работать в любом дистрибутиве… В венде это пипец потому одно из них умеет писать само второе не умеет само но если поставить левый софт то писать будет третье вообще упоротое и не пишет ничем и никак.

init_6 ★★★★★
()
Ответ на: комментарий от init_6

И вот из crossover в wine попадает всяко больше чем из этэрсофта.

Я бы так не утверждал. CodeWeavers использует Wine для своих целей и делится с проектом на тех же основаниях, что и EterSoft. Так что, можешь брать код и сравнивать, кто больше. На самом деле, вполне допускаю, что CodeWeavers больше, но вот про поддержку USB ссылка на EterSoft, к примеру, а не на CodeWeavers.

AS ★★★★★
()
Ответ на: комментарий от AS

На самом деле, вполне допускаю, что CodeWeavers больше, но вот про поддержку USB ссылка на EterSoft, к примеру, а не на CodeWeavers.

Изначально wine это то что отдавал CodeWeavers дальше понятно что там кто-угодно… А разговр был про „недостатки“ ФС в GNU/Linux и ВНЕЗАПНО вклад EterSoft-а в решение этой проблемы… А точнее ОЙ не вклад а небольшой срачик про то как всё плохо и без каких бы то ни было решений фиксов и т.п. Как всегда ни о чем.

init_6 ★★★★★
()
Ответ на: комментарий от init_6

GNU/Linux ≠ Linux, а ты пытаешься сделать вид, что на мобильниках — GNU/Linux. Генту-префиксы ставят единицы, несравнимые даже с долей виндофонов.

Андроид может быть хоть сотню раз линуксом, но он — не GNU/Linux (кроме тех случаев, когда фанатику нужно доказать, что GNU/Linux доминирует на мобильных девайсах).

x3al ★★★★★
()
Ответ на: комментарий от init_6

Изначально wine это то что отдавал CodeWeavers

Ну ладно. Пусть так.

А разговр был про „недостатки“ ФС в GNU/Linux и ВНЕЗАПНО вклад EterSoft-а в решение этой проблемы…

Это - единственное место, где я увидел сводное описание всех проблем. И у них уже есть работающее решение для btrfs.

и без каких бы то ни было решений фиксов и т.п

Отнюдь.

AS ★★★★★
()
Ответ на: комментарий от x3al

GNU/Linux ≠ Linux, а ты пытаешься сделать вид, что на мобильниках — GNU/Linux.

Можешь играть в философа дальше сколько тебе будет угодно а андроид это и есть такой-же GNU/Linux поскольку такое-же ядро linux тот же busybox и coreutils а остальное несущественно. И да чуть менее чем вообще такие-же открытые компоненты. Но да есть и блобы и анальная огороженность загрузчиков и прочие косяки…

init_6 ★★★★★
()
Ответ на: комментарий от AS

Это - единственное место, где я увидел сводное описание всех проблем. И у них уже есть работающее решение для btrfs.

Если бы длина имени файла действительно была бы настолько существенной проблемой её бы уже давно начали бы фиксить или по крайней мере закладывать в новые ФС с запасом…

init_6 ★★★★★
()
Ответ на: комментарий от init_6

Если бы длина имени файла действительно была бы настолько существенной проблемой

Я уже писал, что проблема эта только для славян в большинстве. Возможно, ещё у арабов проблемы есть. Латинские символы в utf8 кодируются одним байтом, всякие умляуты и т.п. не являются подавляющим большинством. В случае же кириллицы длинна имени файла гарантированно уменьшается в два раза, до 127 символов. Иероглифы занимают гораздо больше байт на символ, но и сам иероглиф означает очень много. Китайцам и японцам 255 байт хватает тоже.

Таким образом, это фатальная проблема для тех, кому надо в Linux utf8 и, при этом, более 127 на имя файла. У тебя вот какая кодировка системная ? Я, как на utf8 перешёл, уже столкнулся пару раз. У меня была возможность забить, но некоторые, например, хранят полные названия документов в ФС... База файловая заготовлена в Windows и хрен ты её в Linux перенесёшь без правки имён файлов. Или прощай utf8.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от EvilFox

Суть в том что в Windows и Mac OS X давно из коробки 255 UTF-16 знаков на имя файла, а в GNU/Linux всё ещё этого нет.

4.2

я не знаю как в макоси, но в маздае 265 БАЙТОВ. Увы, из-за совместимости это не изменить. Старый говнокод сломается. А без старого говнокода сама винда никому не нужна, она нужна лишь потому, что в ней работают старые говноподелия, например на дельфи из 90х годов прошлого века.

emulek
()
Ответ на: комментарий от AS

У тебя вот какая кодировка системная ?

utf8

Я, как на utf8 перешёл, уже столкнулся пару раз.

Я не сталкивался ни разу. Я чаще баги с кодировками в архивах наблюдаю.

А вообще про ФС в последнее время я юзал ext4 в lvm2 в luks этот конфиг у меня прожил долго… Фактически до кончины ноута. Всмысле ноут еще окончательно не почил… но уже близок к этому. Что юзать дальше пока особо не думал но btrfs в целом выглядит интересно.

init_6 ★★★★★
()
Ответ на: комментарий от AS

Нет, тут проблема есть.

это проблема исключительно венды, т.к. она до сих пор на cp1251. Я тоже могу перейти на cp1251, и проблем у меня не будет с этими файлами, как в венде. Проблема будет у маздайщиков, ибо я на 1251 переходить не собираюсь, а UTF-8 это говно до сих пор не научилось.

emulek
()
Ответ на: комментарий от init_6

Лично мне по барабану сколько оно умеет или не умеет… Я ни одного раза не сталкивался с такими ограничениями ФС в GNU/Linux которые бы сделали мою жизнь не комфортной.

иногда бывает. Либо файл, который в 1251 по-русски и из 200 букв, тут не перевести в UTF-8, ибо 400 букв получается, либо файлы в 260 байт, которые в маздае работают, а в линуксе — увы, чутка не влезают.

Впрочем, для этого придумали xattr.

emulek
()
Ответ на: комментарий от AS

Китайцам и японцам 255 байт хватает тоже.

Да ладно, у некоторых японских групп (вроде An Cafe) одно название трека будет под 200 байт, а если ещё исполнителя добавить — точно не влезет.

x3al ★★★★★
()
Ответ на: комментарий от init_6

андроид это и есть такой-же GNU/Linux

4.2

это закрытая проприентарщина. там только ядро в сферическом вакууме GNU/Linux, но ядро само по себе бесполезно.

emulek
()
Ответ на: комментарий от x3al

Из общего тут одно ядро.

И что? Мне втулить вот прям сейчас gentoo на свою мобилу мешает только лень убивать sd карточку под это дело. Но если это сделать там будет полноценная gentoo со всем деревом портежей. Так что linux оно или нет лично мне по барабану до тех пор пока я легко, просто и непринужденно могу даже туда впихнуть gentoo.

init_6 ★★★★★
()
Ответ на: комментарий от init_6

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

пофиксили давно. Man xattr. И вводи какие хочешь имена.

А вот само имя файла это ключ в индексе, оно и не должно быть большим. И его никто никогда и не будет делать большим. 255 байт вполне достаточно, или 265, как в маздае.

emulek
()
Ответ на: комментарий от AS

База файловая заготовлена в Windows и хрен ты её в Linux перенесёшь

это проблема СУБД ваще-то.

emulek
()
Ответ на: комментарий от emulek

это закрытая проприентарщина.

Тебя сырцами этой „закрытой проприетарщины“ на охренеть сколько гиг удивить? И да там есть закрытые компоненты так же как и на вообще любом десктопе обычного GNU/Linux. Если уж докапываться до вообще каждой запятой так на любой системе есть BIOS, прошивки wifi и т.д. т.е. блобы.

init_6 ★★★★★
()
Ответ на: комментарий от emulek

а UTF-8 это говно до сих пор не научилось.

Ещё раз, по буквам: в utf8 и во многих FS, и в Linux VFS ограничение на длинну имени файла - 127 русских символов. 127, а не 256. Так понятно ? Похрену совершенно на Windows, и что она там умеет, или не умеет.

это проблема СУБД ваще-то.

Тебе слово «файловая» ни о чём не говорит ? :-) Поясню: куча файлов, имена которых соответствуют названиям каких-то там документов.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от init_6

Тебя сырцами этой „закрытой проприетарщины“ на охренеть сколько гиг удивить?

удиви. Интересует серверная часть гуглодиска например.

И да там есть закрытые компоненты так же как и на вообще любом десктопе обычного GNU/Linux.

белены объелся? В Slackware Linux такого нет.

Если уж докапываться до вообще каждой запятой так на любой системе есть BIOS, прошивки wifi и т.д. т.е. блобы.

при чём тут firmware? Какое отношение они имеют к десктопу/лаптопу/планшету и ПО в нём?

emulek
()
Ответ на: комментарий от x3al

у некоторых японских групп (вроде An Cafe) одно название трека будет под 200 байт

Ну так 200 же, а не 256. Исполнителю надо сколько иероглифов ?

AS ★★★★★
()
Ответ на: комментарий от AS

11 символов. Из них 9 в CJK, оставшиеся 2 имеют право быть широкими. И это далеко не рекордсмены.

x3al ★★★★★
()
Ответ на: комментарий от emulek

А без старого говнокода сама винда никому не нужна

Да-да, всем нужен линукс, ага. Такой весь из себя качественный и бесплатный.

anonymous
()
Ответ на: комментарий от CoolAller

Эмм, так у меня как раз и стоит 4.3.9-2 и все равно показывает, что уязвим к CVE-2014-7186 (redir_stack bug). Он у вас после установки еще и патченный из дебиановских реп апдейт-секьюрити?

нет, из тестинга как поставился, тот и есть. у пакета из stable-security ниже и приоритет, и версия.
вот, запустил свежую версию скрипта специально из-под nobody, чтоб с чистым профилем:

>15:03:48 275 /tmp$ sudo -u nobody /bin/bash
[sudo] password for dimas: 
nobody@Ulf:/tmp$ wget -nv "https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck"
2014-10-02 15:04:05 URL:https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck [2784/2784] -> "bashcheck" [1]
nobody@Ulf:/tmp$ chmod 700 bashcheck
bashcheck      bashcheck.tmp  
nobody@Ulf:/tmp$ rm bashcheck.tmp 
nobody@Ulf:/tmp$ chmod 700 bashcheck 
nobody@Ulf:/tmp$ ./bashcheck 
Testing /bin/bash ...
GNU bash, version 4.3.25(1)-release (x86_64-pc-linux-gnu)

Variable function parser pre/suffixed [(), redhat], bugs not explitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)
nobody@Ulf:/tmp$ apt-cache policy bash
bash:
  Установлен: 4.3-9.2
  Кандидат:   4.3-9.2
  Таблица версий:
     4.3-10 0
         50 ftp://ftp.ru.debian.org/debian/ unstable/main amd64 Packages
 *** 4.3-9.2 0
        990 ftp://ftp.ru.debian.org/debian/ testing/main amd64 Packages
        100 /var/lib/dpkg/status
     4.2+dfsg-0.1+deb7u3 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
     4.2+dfsg-0.1 0
        500 ftp://ftp.ru.debian.org/debian/ wheezy/main amd64 Packages
     4.1-3 0
        500 ftp://ftp.ru.debian.org/debian/ squeeze/main amd64 Packages
в анстэйбл опять что-то новое прилетело...

PerdunJamesBond
()
Ответ на: комментарий от emulek

но в маздае 265 БАЙТОВ

Это ты откуда взял?
Я вот только что создал файлы:

яяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя

и

私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私私

EvilFox ★★
()
Ответ на: комментарий от anonymous

Да-да, всем нужен линукс, ага.

ага. Сами десктопы уже отживают своё. А венда работает только на PC, её не засунешь ни в роутер, ни в суперкомпьютер. Даже в планшет/телефон не получилось.

emulek
()
Ответ на: комментарий от EvilFox

Я вот только что создал файлы

AFAIK там у тебя какой-то костыль вроде нашего xattr(а может xattr и есть, я не в курсе). Т.е. это не имена. Да, работают, ну и что? В Slackware тоже работает.

emulek
()
Ответ на: комментарий от emulek

удиви. Интересует серверная часть гуглодиска например.

А при чем здесь серверная часть гуглодиска к сырцам самой прошивки? Андроид открытая система. Иначе были-бы невозможны десятки форков на его основе: CyanogenMod, MIUI, Replicant…

белены объелся? В Slackware Linux такого нет.

Окай так и запишем. Что есть или чего нет в конкретном дистре только вопрос выбора соответствующего дистростроителя а в целом блобы на графику, wifi это иной раз единственный способ добиться от железа его номинального режима работы.

при чём тут firmware? Какое отношение они имеют к десктопу/лаптопу/планшету и ПО в нём?

firmware ВНЕЗАПНО как ты не отмазывайся но такой же блоб. И без всех этих блобов систем исчезающе крайне мало. Поэтому говорить что в „Slackware Linux такого нет“ на обычном PC с BIOS как минимум глупо потому что вместе со слакой у тебя работает BIOS который ВНЕЗАПНО блоб и плевать на то что там есть или чего там нет в твоей слаке.

init_6 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.