Компания Oracle опубликовала (https://blogs.oracle.com/oraclesecurity/january-2018-critica...) плановый выпуск обновлений своих продуктов (Critical Patch Update), нацеленный на устранение критических проблем и уязвимостей. В январском обновлении в сумме устранено 237 уязвимостей (http://www.oracle.com/technetwork/security-advisory/cpujan20...), в том числе в некоторые продукты внесены исправления для блокирования атак Spectre и Meltdown (https://www.opennet.dev/opennews/art.shtml?num=47856).В выпусках Java SE 8u161/8u162 и 9.0.4 (http://www.oracle.com/technetwork/java/javase/downloads/inde...) устранена 21 проблема с безопасностью, 18 из которых могут быть эксплуатированы удалённо без проведения аутентификации. 3 уязвимостям присвоен (http://www.oracle.com/technetwork/security-advisory/cpujan20...) уровень опасности 8.3, критических проблем с CVSS Score 9 и выше в этот раз не выявлено. 7 проблем проявляются только на клиентских системах (запуск в браузере Java Web Start и Java-апплеты) и 10 затрагивают как клиентов, так и серверные конфигурации Java.
Кроме проблем в Java SE, наличие уязвимостей обнародовано и в других продуктах Oracle, в том числе:
- 22 уязвимости (http://www.oracle.com/technetwork/security-advisory/cpujan20...) в MySQL (максимальный уровень опасности 7.5), из которых 3 позволяют выполнить атаку удалённо без прохождения аутентификации. Проблемы устранены в выпусках MySQL Community Server 5.7.21, 5.6.39 и 5.5.59 (http://dev.mysql.com/downloads/mysql/).
- 12 уязвимостей (http://www.oracle.com/technetwork/security-advisory/cpujan20...) в VirtualBox (максимальная степень опасности 8.8). В том числе добавлена защита от проведения атаки Spectre. Уязвимости устранены в сегодняшних обновлениях VirtualBox 5.2.6 и 5.1.32 (https://www.virtualbox.org/).
- 5 проблем (http://www.oracle.com/technetwork/security-advisory/cpujan20...) в Solaris (максимальная степень опасности 7.1, крах ядра при обработке некорректных пакетов ICMP).
URL: https://blogs.oracle.com/oraclesecurity/january-2018-critica...
Новость: http://www.opennet.dev/opennews/art.shtml?num=47920
> в том числе в некоторые продукты внесены исправления для блокирования атак
> Spectre и Meltdown (https://www.opennet.dev/opennews/art.shtml?num=47856).теперь будет тормозить еще и virtualbox
> в Solaris (максимальная степень опасности 7.1, крах ядра при обработке некорректных
> пакетов ICMP).а в illumos добро пожаловать с ping-of-death ?
Да он и так тормозит, потому что работает на ОС с "патчами"
Последние ядра в Ubuntu обновились, потерялось 50% производительности в VirtualBox при активной работе с кучей. Чувствуешь себя обманутым наперсточниками.
Моё исследование производительности (на примере парсера, который пускаю в VB, потому что большая часть кода общая с GUI под винду)
1. linux-image-4.13.0-26-generic, VB 5.2.4, винда без патчей -- 0:48 - меньше минуты(!)
2. linux-image-4.13.0-29-generic, VB 5.2.4, винда без патчей -- 1:20 - потери >50%
3. linux-image-4.13.0-30-generic, VB 5.2.6, винда без патчей -- 3:24 - комментарии излишниСразу возникают вопросы:
1. Каким образом в Google не просела производительность
2. Мне что, для работы две машины теперь держать - одну в изоляции без патчей, а другую с патчами?
3. Intel все, его больше не берем, потому что как на Atom 2009 года пересел
4. А если ещё на винду патчи поставить?
> А если ещё на винду патчи поставить?А ты налей и отойди (с)
> Моё исследование производительности (на примере парсера, который пускаю в VB, потому что
> большая часть кода общая с GUI под винду)
> 1.
>0:48 - меньше минуты(!)
> 2.
>1:20 - потери >50%Арифметику пора повторить, устный счёт подтянуть.
$ echo 'scale=2;a=1*60+20;b=48;(a-b)/a*100' |bc
40.00
$ _
> Сразу возникают вопросы:
> 1. Каким образом в Google не просела производительностьВнимательно читаем:
05.01.2018 23:26 Google считает незначительным влияние на производительность патчей для блокирования атак Meltdown и Spectre
"считает незначительным" != "не просела"
>> Моё исследование производительности (на примере парсера, который пускаю в VB, потому что
>> большая часть кода общая с GUI под винду)
>> 1.
>>0:48 - меньше минуты(!)
>> 2.
>>1:20 - потери >50%
> Арифметику пора повторить, устный счёт подтянуть.
> $ echo 'scale=2;a=1*60+20;b=48;(a-b)/a*100' |bc
> 40.00
> $ _$ if (( 60 + 20 > 48 + 48/2 )); then echo больше; else echo не; fi
больше
>> $ echo 'scale=2;a=1*60+20;b=48;(a-b)/a*100' |bc
>> 40.00
> $ if (( 60 + 20 > 48 + 48/2 )); then
> echo больше; else echo не; fi
> больше;b=48;(a-b)*100./b' |bc
66.66Сажусь, двойка.
Да начнется битва математиков за истину :)Выступлю на стороне Андрея. Потраченное время обратно пропорционально производительности. Надеюсь не надо объяснять почему. Считаем производительность в попугаях: P1=1/48; P2=1/80; Смотрим сколько процентов от P1 составляет P2: P2/P1=80/48=0.6. То есть падение производительности на 40%. Затраченное время при этом растет на другую величину.
Вообще для упрощения понимания таких случаев надо ставить экстремальные значения, например 99.99%.
Арифметика тут не причем - я только скорость парсинга показывал (мне же сидеть в отладчике на минуту дольше!) - ещё прочитать и подготовить к парсингу файлы - там вообще без комментариев: было 10 - стало 30-35, но там ФС кеширует, так что норм - последующие запуски уже не напрягают. Как раз и получается - чуть больше 50%.
4. linux-image-4.13.0-26-generic, VB 5.2.6, винда без патчей -- 1:08 - исправили, так исправили
5. linux-image-4.13.0-26-generic, VB 5.2.4, винда без патчей -- 0:48 - полный откат
При определении процента изменений, в качестве основания обычно берут исходную величину (48), а не новую - 80. т.е. 32/48=0,66[6]
А чё, собрать и установить кастомное ядро Linux без патчей не осиливаем?
А какие цифры если сделать
echo 0 > /sys/kernel/debug/x86/pti_enabled
?
Не влияет. Никак!
> 1. Каким образом в Google не просела производительностьпросела, "считают незначительным" (читай - у нас настолько много денег, что даже если придется удвоить количество картонок в контейнерах - мы не заметим)
> 2. Мне что, для работы две машины теперь держать - одну в
> изоляции без патчей, а другую с патчами?и чем это поможет?
> 4. А если ещё на винду патчи поставить?
меня изумляет, почему ты этого еще не сделал - у тебя прекрасный тестовый стенд, с известными показателями производительности, есть с чем сравнивать, сделай снапшот да и поставь.
Мне, к примеру, интересно было бы увидеть результаты.
>>> и чем это поможет?Ну сейчас у меня для этих целей виртуалка - в мир смотрит только полностью обновленный хост, а гость никуда не смотрит, сидит себе в виртуалке
>>> почему ты этого еще не сделалзачем мне в гостевой нужны патчи для хоста?
>>>> и чем это поможет?
> Ну сейчас у меня для этих целей виртуалка - в мир смотритдык - прикол в том, что память прекрасно протекает и между виртуалками - тоже.
>>>> почему ты этого еще не сделал
> зачем мне в гостевой нужны патчи для хоста?у нее _собственная_ таблица страниц - так что она точно так же уязвима. Даже если хост ты запатчил.
Оффтопик на работе с VisualStudio в режиме дебага после патчей стал тормозить ещё круче, плюс иногда виснет. Эти патчи - сплошная боль. И даже непонятно, когда ждать нормальных процов с пофикшенной уязвимостью (не кривым фиксом на фирмварь, точно так же убивающим перфоманс, а именно новые пофикшенные)
> даже непонятно, когда ждать нормальных процов с пофикшенной уязвимостью (не кривымесли у тебя денег больше чем у гугля - непоянтно, зачем чего-то ждать.
У серых ничтожеств, в отличие от вас, нет возможности сменить процессоры на "нормальные", не поменяв заодно материнки и память, которые, разумеется, несовместимы.
У тебя ко мне очень странные предъявы...
Ты забыл включить мозг?
Я не предлагаю менять материнки и прочее. Я спрашиваю, когда ХОТЯ БЫ для продающихся сегодня материнок выйдут исправленные процессоры, чтобы знать, сколько месяцев не стоит ничего вообще покупать, дабы серым типа меня не платить дважды (за хреновый проц и за второй).
Ты ещё обидься на меня, что патчи к win95 на данную уязвимость Microsoft не написал
> Я спрашиваю, когда ХОТЯ БЫ для продающихся сегодня материнока, ну так кто забыл включить мозг-то? Никогда. По тем же причинам, по которым нет патчей для win95(кстати, ей и не нужны, там по сути нет изоляции процессов)
Ну кроме может быть самых распоследних CoffeeLake, которые не существуют и не планируются в серверных сериях. платы для них "сегодня продаются", но тебе от этого, полагаю, не жарко и не холодно.
Серию на замену KabyLake безусловно выпустят еще до конца года, но очень навряд ли ее можно будет втыкать в 1151 или даже в xeon'овые слоты. (что, собственно, уже имеем с десктопной серией, где даже слот называется 1151...но это не тот 1151, и старые i7 туда поставить нельзя ;-)
> Ты ещё обидься на меня, что патчи к win95 на данную уязвимость Microsoft не написал
лучше б он их ни к чему не написал, а то сиди теперь вечно без апдейтов - в том числе будущих, которые будут исправлять другие проблемы. Поскольку нет ни малейшей гарантии, что в них заодно не улучшат что-нибудь в исправлении исправления, и оно не достанется даже тем, кто сумел пропустить 10.01 (включая владельцев amd, которым оно нахрен не вперлось)
> 5 проблем в Solaris (максимальная степень опасности 7.1 - проблемы в ядре, связанные с обработкой пакетов ICMP)А оно разве не закoпано ещё?
Оно ещё нас с тобой переживёт.
Ну раве только если оракалы его в Apache Foundation спихнут :)
Thursday, January 26, 2017Long live Solaris 11! - Until at least 2034 to be exact
By: Gerry Haskins | Director Security and Release Management
In case you haven't heard, the Solaris 11 support dates have been extended by 10 years to 2031 for Premier Support and 2034 for Extended Support. This provides long term protection for customers' investment in Solaris. See page 34 (page 37 in the PDF) of the Oracle Lifetime Support Policy: Oracle and Sun Systems Software.
This is because Oracle Solaris is moving to a continuous delivery model using more frequent updates to deliver the latest features faster, while fully preserving customer and ISV qualification investment in the vast array of ISV applications available on Oracle Solaris 11 today.
New features and functionality will be delivered in Oracle Solaris 11 through “dot” update releases (11.x), instead of major releases. See https://blogs.oracle.com/solaris/entry/oracle_solaris_moving....
This is consistent with industry trends and addresses customer requirements for a smooth transition path between versions, providing ongoing innovation with assured investment protection.
By moving to a continuous delivery model based on Oracle Solaris 11, customers will have a seamless update experience to better fit their move to agile deployment models.
I've updated my Overview of Solaris Release Cadence to reflect the changes and I'm in the process of updating the corresponding Doc 2114039.1.
And in case you're wondering, SPARC development also continues apace. See The Oracle SPARC and Oracle Solaris roadmap.
Personally, I'm taking on an expanded role as the Release Management Director, so my job will be to get the products on the roadmap released on time, with the quality you've come to expect. No pressure so! :)
Best Wishes,
Gerry.
https://blogs.oracle.com/solaris11life/long-live-solaris-11-...
ТоварищЪ - верЬ! (С)
> ТоварищЪ - верЬ! (С)Когда закончатся винды, пингвины, бзди и маки, я буду посмеиваться, глядя на упадок мира из своей Солярки 11.
>проблемы в ядре, связанные с обработкой пакетов ICMPping of death в 2018м году?
>>проблемы в ядре, связанные с обработкой пакетов ICMP
> ping of death в 2018м году?все нормально, этот код Sun писала в 1998-м
>В выпусках Java SE 8u161/8u162 и 9.0.4 устранена 21 проблема с безопасностью.В managed языках не может быть уязвимостей! Вы врёти
И доказательством этого выступает Пыхпых
люто ... пых нынче - managed? :-)))))
> люто ... пых нынче - managed? :-)))))Если на один пых, то да. Если на больше, то надо смотреть.
Нет, что ты, там ручное выделение/освобождение памяти и адресная арифметика.
>В managed языках не может быть уязвимостей! Вы врётиВообще-то уязвимости в JVM, которая написана на могучем си... ещё вопросы?
>>В managed языках не может быть уязвимостей! Вы врёти
> Вообще-то уязвимости в JVM, которая написана на могучем си... ещё вопросы?https://www.openhub.net/p/openjdk
> Java 71% XML 9% C++ 11% 19 Other 9%https://github.com/dmlloyd/openjdk
> Java 78.9% C++ 11.8% C 4.8% JavaScript 1.2% Roff 1.0% Shell 1.0% Other 1.3%Давно бы переписали эти несчастные 11% на жабу, если все ошибки лезут оттуда.
>Давно бы переписали эти несчастные 11% на жабу, если все ошибки лезут оттуда.Вы перепутали, безопасность и скорость это то, на что сишники др.чат (но с первым у них ещё хуже, чем у жабистов).
Вообще, подавляющее большинство "страшных дырок в hotspot" это "applies to clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code and rely on the Java sandbox for security"
только эксперты опеннета по ссылкам не ходют жеж
> Вообще, подавляющее большинство "страшных дырок в hotspot" это "applies to clients running
> sandboxed Java Web Start applications or sandboxed Java applets, that load
> and run untrusted code and rely on the Java sandbox for security"Ну да, проблемы с безопасностью песочницы и не проблемы вовсе, а так - тьху и растереть. А песочница для красоты и маркетинга, а не безопасности.
> только эксперты опеннета по ссылкам не ходют жеж
Самокритично, однако )
>Ну да, проблемы с безопасностью песочницы и не проблемы вовсе,Назови хоть ОДНУ песочницу, которую ни разу не сломали. Или свободен...
От КубеОС до песочницы того же Хромого (который аналогично запускает untrusted code and rely on the sandbox for security" - всё решeto
>>Ну да, проблемы с безопасностью песочницы и не проблемы вовсе,
> Назови хоть ОДНУ песочницу, которую ни разу не сломали. Или свободен...Да-да, а cпектр на самом деле тоже не дыра на десктопах, потому что нет немаргинальных десктопных процов без нее, это знают все и это логично, потому что мы все так повторяем!1 )))
Для начала тогда давай нормальный источник на
> подавляющее большинство "страшных дырок в hotspot" это "applies to clients running sandboxedЭто раз.
А теперь объясни (по возможности, без излишней жестикуляции, брызг слюной, полыханий и проч), с какого перепугу дыра в песочнице не дыра вовсе, только потому что песочниц без дыр не бывает?
А то отдает какой-то извращенно-маркетоидной логикой, особенно учитывая, что при этом "сравнении" почему-то напрочь игнорируется количество дыр в песочницах, как будто тот же Хром(иум) — маргинальнейшая маргинальщина и полагается только на принцип неуловимого Джо.