exploits for network stack like CVE-2014-2523 and Qubes
https://groups.google.com/forum/#!topic/qubes-users/4usaW-cSkIc
Если в кратце, то меня, за отсутсвием времени копаться в деталях, интересуют подробности работы CVE-2014-2523, а именно:
------------------------------------------------------------------------------------
So please confirm (and if possible - explain) this questionable statements:
0. The deals with protocol numbers in the stack do not allow errors
made in parsing some protocol to execute any data ever in any case.
1. The Qubes provides security from exploits made for network stack
that work before the TCP/IP connection is subject to deal with, but
work directly on receive by the buggy stack (see above related to
table 'raw').
2. This one CVE is the type that doesn't affect Qubes at all since it
doesn't work the way described in 1.
Thanks in advance.
------------------------------------------------------------------------------------
Подробности в url выше.
Если Вы не знаете деталей Qubes, но можете рассказать за какой нибудь hardened linux - welcome. :)
Ну или просто поясните детали из оригинала, потому как я за неимением времени разобраться сделал выводы из обзора на opennet.
update: https://groups.google.com/forum/#!topic/qubes-devel/GnEfhJUgDHY - я тут по английски изложил, что самые страшные атаки
срабатывающие в IP-стэке можно поделить на 3 типа применительно к linux:
1ые стряляют при входе в стэк до обработчика table raw.
2ые стреляют в самом обработчике table raw.
3и стреляют после обработчика table raw. Для борьбы с ними есть workaround.
Я на одном из своих linux девайсов вообще запретил все протоколы которые я предположительно не использую и это теперь, на мой взгляд, правильный дефолт для любого безопасного построения таблиц фильтрации.
В Qubes очень хорошо продумана архитектурно изоляция, но я пока недостаточно понимаю Qubes чтобы быть спокойным за AppVM которая стоит за цепочкой NetVM-FirewallVM в случаях когда речь идёт об эксплойтах типа 1 и 2.
В нормальном линухе это pown. В Qubes в худшем случае это pown цепочки NetVM-FirewallVM-AppVM и никаких шансов добраться без эксплойта к специфичной имплементации Xen к цепочке NetVM-FirewallVM-AppVM подключенной к другой физической сети, ну и никаких шансов без такого эксплойта добраться к Dom0 или StandaloneVM. Аудит Xen кода используемого Qubes проведён Джоанной и её командой, они не берут патчи которые считают небезопасными, а это уже немало. Более грамотных людей я просто пока не знаю. Ну может кое-кто из Xen devel и то не факт что они эксперты по взлому и защите, а не по виртуализации как таковой.
В итоге Qubes по прежнему впереди всех. Было бы круто если бы Joanna и команда объяснили для меня и всего мира нюансы борьбы с типами 1 и 2 хотя бы и на уровне недоступном к пониманию непосвящёнными в практический ядерный хакинг. Было бы что поизучать в свободное время. :)~
update: что касаемо конкретно этого уязвимого участка:
-------------------------------------------------------------
struct dccp_hdr _dh, *dh;
...
skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);
а должно было быть
skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh);
-------------------------------------------------------------
quoted from http://grey-olli.livejournal.com/852440.html comment, thanks to watchcat@livejournal.
Если в кратце, то меня, за отсутсвием времени копаться в деталях, интересуют подробности работы CVE-2014-2523, а именно:
------------------------------------------------------------------------------------
So please confirm (and if possible - explain) this questionable statements:
0. The deals with protocol numbers in the stack do not allow errors
made in parsing some protocol to execute any data ever in any case.
1. The Qubes provides security from exploits made for network stack
that work before the TCP/IP connection is subject to deal with, but
work directly on receive by the buggy stack (see above related to
table 'raw').
2. This one CVE is the type that doesn't affect Qubes at all since it
doesn't work the way described in 1.
Thanks in advance.
------------------------------------------------------------------------------------
Подробности в url выше.
Если Вы не знаете деталей Qubes, но можете рассказать за какой нибудь hardened linux - welcome. :)
Ну или просто поясните детали из оригинала, потому как я за неимением времени разобраться сделал выводы из обзора на opennet.
update: https://groups.google.com/forum/#!topic/qubes-devel/GnEfhJUgDHY - я тут по английски изложил, что самые страшные атаки
срабатывающие в IP-стэке можно поделить на 3 типа применительно к linux:
1ые стряляют при входе в стэк до обработчика table raw.
2ые стреляют в самом обработчике table raw.
3и стреляют после обработчика table raw. Для борьбы с ними есть workaround.
Я на одном из своих linux девайсов вообще запретил все протоколы которые я предположительно не использую и это теперь, на мой взгляд, правильный дефолт для любого безопасного построения таблиц фильтрации.
В Qubes очень хорошо продумана архитектурно изоляция, но я пока недостаточно понимаю Qubes чтобы быть спокойным за AppVM которая стоит за цепочкой NetVM-FirewallVM в случаях когда речь идёт об эксплойтах типа 1 и 2.
В нормальном линухе это pown. В Qubes в худшем случае это pown цепочки NetVM-FirewallVM-AppVM и никаких шансов добраться без эксплойта к специфичной имплементации Xen к цепочке NetVM-FirewallVM-AppVM подключенной к другой физической сети, ну и никаких шансов без такого эксплойта добраться к Dom0 или StandaloneVM. Аудит Xen кода используемого Qubes проведён Джоанной и её командой, они не берут патчи которые считают небезопасными, а это уже немало. Более грамотных людей я просто пока не знаю. Ну может кое-кто из Xen devel и то не факт что они эксперты по взлому и защите, а не по виртуализации как таковой.
В итоге Qubes по прежнему впереди всех. Было бы круто если бы Joanna и команда объяснили для меня и всего мира нюансы борьбы с типами 1 и 2 хотя бы и на уровне недоступном к пониманию непосвящёнными в практический ядерный хакинг. Было бы что поизучать в свободное время. :)~
update: что касаемо конкретно этого уязвимого участка:
-------------------------------------------------------------
struct dccp_hdr _dh, *dh;
...
skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);
а должно было быть
skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh);
-------------------------------------------------------------
quoted from http://grey-olli.livejournal.com/852440.html comment, thanks to watchcat@livejournal.