Сильно сомневаюсь, что Safari не использует strtod (как минимум для перевода Content-Length, не говоря уже о яваскрипте) — так что скорее всего просто не указана.
Я это все понимаю, вот только Вы действительно считаете, что эти «17 лет», которые баг был неизвестным сравнимы с теми 7 месяцами, которые известен (и не пофикшен) баг в dtoa/strtod?
Ну и да, несмотря на все написанное LPE баги несравнимы с RCE.
И да, выставлять «наружу» любые ненужные извне сервисы — это плохая примета.
Баг не в «сервисе», а в библиотеке. Библитеке, которая используется огромным количеством обычного клиентского софта. В том числе и браузерами/почтовиками.
На самом деле они пытаются побить собственный рекорд. Чуть менее года (с августа 2008 по июнь 2009) с «remote code execution» багом в дефолтном компоненте системы. В тот раз Apple-у понадобился всего месяц после выпуска эксплоита.
Еще один забавный момент: в прошлый раз фикс был написан Sun-ом и Apple-у потребовалось всего полгода, чтобы выпустить патч с этим фиксом, в этот раз все уже тоже давно пофикшено другими вендорами.
1. Вы действительно не отличаете «local privilege escalation» от «remote code execution»?
2. Вы действительно не отличаете «возраст» кода от «возраста» обнаруженной уязвимости?
Вы таки будете удивляться, но да. Причем я об этом уже упоминал
Ну и когда дойдете до раздела «Lack of support in Linux» остановитесь на секундочку и подумайте, может вместо выкрикивания лозунгов про «запускалки для игр» стоит заняться самообразованием?
А у нас в ядре тоже все асинхронно (в смысле в первую очередь потому что все асинхронно там, все асинхронно и выше). В отличие от. Но вы похоже не улавливаете суть. Если не доверяете «классовым врагам» — почитайте что пишут ваши же (вот прямо с первого раздела Motivation и начинайте).
Именно для сетевых приложений тот же IOCP используется наиболее широко (хотя в тех же БД тоже нередко). И да, современные сетевые карты со скоростями передачи 1-10 gbps ТОЛЬКО DMA и используется (плюс куча других техник, типа того же TOE, которого в запускалке желейных окошек нет и не предвидится).
Желтуха такая желтуха. Заметка написана так, чтобы создать впечатление что в МС поменяли свое мнение и «милостиво согласились» залатать IE. В то время, как даже даже отказа от out-of-cycle патча изначально не было. Вот оригинальный advisory. Читаем:
At this time, we are aware of limited, targeted attacks attempting to use this vulnerability against Internet Explorer 6. We have not seen attacks against other versions of Internet Explorer. We will continue to monitor the threat environment and update this advisory if the situation changes. On completion of this investigation, Microsoft will take appropriate action to protect our customers, which may include providing a solution through our monthly security update release process, or an out-of-cycle security update.
Еще раз для тех, кто не понял:
may include [skipped] an out-of-cycle security update.
Более того, уязвимы для remote code execution только пользователи IE6. Для IE7 — это DoS (закрытие приложения). Для IE8 — просто закрытие вкладки с вредоносным кодом. В принципе можно было бы и во «второй вторник» выпустить обновление — оно не критичное (те, у кого до сих пор IE6 — просто не ставят никаких обновлений, а на остальных атака и не действует), но благодаря вот таким вот пасквилям, вопрос перешел из технической сферы в имиджевую.
Ну и к чему пост? Только для того, чтобы потеребить свое эго в мнимом противостоянии с Империей Зла?
На всякий случай (чтобы Вы не воспринимали хинт слишком буквально) отмечу, что O_NONBLOCK не имеет ничего общего с асинхронным IO — просто вместо блокирования будет возвращаться ошибка EWOULDBLOCK (чего люди не придумают, лишь бы не писать на нормальном API).
Что значит нельзя? Либо Вы недопонимаете работу каналов, либо я недопонимаю, что Вы имеете в виду. Я могу писать в один конец канала до тех пор, пока не закончится память, отведенная под буферизацию для этого канала — без всяких блокировок. То есть асинхронно.
Да-да, раз нет — значит не нужно. Продолжайте читать мантры про «запускалки для игр», ну а когда появится свободная минутка подумайте о том, что когда Вы выставлете асинхронную операцию чтения, вы сразу же предоставляете буфер, который можно залочить в физической памяти и передать в устройство, а устройство будет читать через DMA напрямую в Ваш буфер. Это первое, что пришло в голову. С select-ом все сначала считается во внутренние буферы, а потом скопируется.
Еще я могу выставить много асинхронных операций в одном потоке и дать каждой функцию, которая вызовется по завершению — удобно же. Да много чего можно сделать из того, что «не нужно».
Вообще select — это «как бы замена» асинхронных операций, но как обычно неполноценная. Подходит только для сокетов (потому что для обычных файлов «ready for reading» или «ready for writing» лишено смысла — они обречены оставаться блокирующими), жутко неудобны в использовании, да и send все так же блокирует.
(кстати это в Линуксе есть, см. вызов sendfile()
Это все та же синхронная операция. Просто комбинация read и write. Даю хинт: асинхронные операции не блокируют вызывающий поток.
Как тут применить асинхронное чтение? «Прочитай первые 2000 байт и возвращайся»?
Вы почитайте про IO Completion Ports — авось перестанете нести чушь в публичных местах.
На всякий случай отвечу — для будущих поколений
"!analyze -v" для double fault-ов прямым текстом говорит: «возможно у вас переполнился стек» — стоит читать что говорит отладчик
Во-вторых, ограниченность kernel-mode стека — одна из первых вещей, которые узнает kernel-developer. Непонятно, как так получилось, что ни Вы ни Ваш «более опытный товарищ» этого не знали
Ну и в-третьих KeExpandKernelStackAndCallout. Хотя для этого придется подождать пока XP сойдет со сцены (надеюсь недолго осталось). А пока — WorkItem-ы/Worker thread-ы и вперед
1. Не считается. Это не асинхронный ввод/вывод, а ожидание момента, когда синхронный ввод/вывод можно произвести без блокировки. Асинхронный это: запустил операцию чтения и вышел — она выполняется в фоне. Я вообще то думал, что Вы вспомните libaio — и уже собирался понасмехаться, но не судьба :-)
По поводу фри — смешно. BSDisALinuxDistro™ ага. В винде тоже белые буквы на черном фоне в командной строке (даже POSIX сертификация есть) — винда тоже линукс? :-)
2. А где Вы видели такое утверждение? В винде «cmd1 | cmd2» использует те же пайпы (только анонимные — создаваемые CreatePipe вместо CreateNamedPipe), что и были протестированы. В линуксе «cmd1 | cmd2» использует пайпы, создаваемые вызовом pipe(2) — именовать их нельзя (для подобия именованых пайпов нужно использовать юникс домейн сокеты — правда очень консистентно?).
1. Надо полагать мы сейчас имеем счастье общаться с экспертом в области проектирования ОС? Расскажите, пожалуйста, что Вы думаете о перспективах внедрения асинхронного ввода/вывода в линуксе. Для нас это очень важно.
2. Видно эксперта с мировым именем. Вы правда считаете, что пайпы cmd1 | cmd2 отличаются от тах, что были протестированы?
3. Оба теста на шарпе — имеем «apples to apples». Кроме того, большая часть времени была проведена в ядре, да и в юзермоде что то мне подсказывает, что CLR-слой там достаточно тонкий и все быстро уходит в нейтив.
Пайпы как раз и используют shared memory на локалхосте. При этом избавляя от необходимости выполнять кучу рутинной работы по созданию, синхронизации и прочему менеджменту этой памяти. Дополнительным плюсом является возможность легкого разноса клиента с сервером на разные машины практически без изменения кода.
Нет, вообще то говорит. NPFS (Named Pipe File System) — это именно что файловая система. Read/WriteFile поддерживает и пр., а вот сокеты — раньше были ПАРОЙ файлов (\Device\Tcp, \Device\Udp и прочих TDI устройств) и вся работа с ними производилась через IOCTL-ы (тоже впрочем асинхронные, как и весь ввод/вывод в NT), а IRP_MJ_READ/IRP_MJ_WRITE этими устройствами даже не поддерживаются. Сейчас, с появлением WSK, все еще интереснее — файлы там не фигурируют вообще (хотя стоит признать, в новой модели я разбираюсь чуть слабее — может и пропустил чего).
В общем я тут умничал только для того, чтобы сказать, что именованые каналы — это обычные файлы с точки зрения как ядерного API, так и Win32 подсистемы, а вот сокеты — это совсем не обычные файлы, я бы даже сказал совсем необычные.
В каком смысле «полностью синхронная»? Вообще то в NT весь ввод/вывод асинхронный (синхронные операции на самом деле это асинхронные + ожидание окончания). Ну а именованные каналы — это обычная файловая система (\Device\NamedPipe который создается, если не ошибаюсь в npfs.sys) и соответственно с ними работают любые асихронные операции: от обычных GetOverlappedResult и Read/WriteFileEx до IOCP.
Так и именованные каналы легко пересекают границы машин.
"\\.\pipe\PipeName" versus "\\remote-machine-name\pipe\PipeName"
Для C# нужно использовать версии конструкторов с указанием имени сервера. Например:
public NamedPipeClientStream(
string serverName,
string pipeName
)
Ну и да, несмотря на все написанное LPE баги несравнимы с RCE.
Баг не в «сервисе», а в библиотеке. Библитеке, которая используется огромным количеством обычного клиентского софта. В том числе и браузерами/почтовиками.
Еще один забавный момент: в прошлый раз фикс был написан Sun-ом и Apple-у потребовалось всего полгода, чтобы выпустить патч с этим фиксом, в этот раз все уже тоже давно пофикшено другими вендорами.
2. Вы действительно не отличаете «возраст» кода от «возраста» обнаруженной уязвимости?
А за что не любите то?
Вы таки будете удивляться, но да. Причем я об этом уже упоминал
Ну и когда дойдете до раздела «Lack of support in Linux» остановитесь на секундочку и подумайте, может вместо выкрикивания лозунгов про «запускалки для игр» стоит заняться самообразованием?
Еще раз для тех, кто не понял:
Более того, уязвимы для remote code execution только пользователи IE6. Для IE7 — это DoS (закрытие приложения). Для IE8 — просто закрытие вкладки с вредоносным кодом. В принципе можно было бы и во «второй вторник» выпустить обновление — оно не критичное (те, у кого до сих пор IE6 — просто не ставят никаких обновлений, а на остальных атака и не действует), но благодаря вот таким вот пасквилям, вопрос перешел из технической сферы в имиджевую.
Ну и к чему пост? Только для того, чтобы потеребить свое эго в мнимом противостоянии с Империей Зла?
Еще я могу выставить много асинхронных операций в одном потоке и дать каждой функцию, которая вызовется по завершению — удобно же. Да много чего можно сделать из того, что «не нужно».
Вообще select — это «как бы замена» асинхронных операций, но как обычно неполноценная. Подходит только для сокетов (потому что для обычных файлов «ready for reading» или «ready for writing» лишено смысла — они обречены оставаться блокирующими), жутко неудобны в использовании, да и send все так же блокирует.
Это все та же синхронная операция. Просто комбинация read и write. Даю хинт: асинхронные операции не блокируют вызывающий поток.
Вы почитайте про IO Completion Ports — авось перестанете нести чушь в публичных местах.
"!analyze -v" для double fault-ов прямым текстом говорит: «возможно у вас переполнился стек» — стоит читать что говорит отладчик
Во-вторых, ограниченность kernel-mode стека — одна из первых вещей, которые узнает kernel-developer. Непонятно, как так получилось, что ни Вы ни Ваш «более опытный товарищ» этого не знали
Ну и в-третьих KeExpandKernelStackAndCallout. Хотя для этого придется подождать пока XP сойдет со сцены (надеюсь недолго осталось). А пока — WorkItem-ы/Worker thread-ы и вперед
По поводу фри — смешно. BSDisALinuxDistro™ ага. В винде тоже белые буквы на черном фоне в командной строке (даже POSIX сертификация есть) — винда тоже линукс? :-)
2. А где Вы видели такое утверждение? В винде «cmd1 | cmd2» использует те же пайпы (только анонимные — создаваемые CreatePipe вместо CreateNamedPipe), что и были протестированы. В линуксе «cmd1 | cmd2» использует пайпы, создаваемые вызовом pipe(2) — именовать их нельзя (для подобия именованых пайпов нужно использовать юникс домейн сокеты — правда очень консистентно?).
2. Видно эксперта с мировым именем. Вы правда считаете, что пайпы cmd1 | cmd2 отличаются от тах, что были протестированы?
3. Оба теста на шарпе — имеем «apples to apples». Кроме того, большая часть времени была проведена в ядре, да и в юзермоде что то мне подсказывает, что CLR-слой там достаточно тонкий и все быстро уходит в нейтив.
В общем я тут умничал только для того, чтобы сказать, что именованые каналы — это обычные файлы с точки зрения как ядерного API, так и Win32 подсистемы, а вот сокеты — это совсем не обычные файлы, я бы даже сказал совсем необычные.
Или Вы что-то другое имели в виду?
"\\.\pipe\PipeName" versus "\\remote-machine-name\pipe\PipeName"
Для C# нужно использовать версии конструкторов с указанием имени сервера. Например:
public NamedPipeClientStream(
string serverName,
string pipeName
)