The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В Chrome OS реализована блокировка доступа к USB во время неактивности

24.12.2018 20:39

В экспериментальной ветке Chrome OS (Canary) тестируется возможность блокирования подключения новых устройств к USB-портам во время действия экрана блокировки системы. Добавленная возможность включается через флаг "chrome://flags/#enable-usbguard" и позволяет защитить оставленное без присмотра устройство от атак через USB-порт, например, проводимых при помощи специального оборудования или инструментария BadUSB. Применяемые пользователем и заслуживающие доверия USB-устройства могут быть добавлены в белый список. Блокировка также не распространяется на устройства, подключенные до блокировки экрана.

  1. Главная ссылка к новости (https://www.chromestory.com/20...)
  2. OpenNews: Новая версия свободного USB-логгера USBSnoop
  3. OpenNews: В USB-стеке ядра Linux выявлено 14 уязвимостей
  4. OpenNews: Представлена техника атаки, позволяющая шпионить за соседними USB-устройствами
  5. OpenNews: USB Canary - утилита для мониторинга портов USB во время блокировки экрана
  6. OpenNews: Атака на заблокированный ПК через USB
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49846-usb
Ключевые слова: usb, chrome
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (29) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 21:59, 24/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Правильный подход!
     
     
  • 2.3, Xasd (ok), 22:51, 24/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Правильный подход!

    неплохо было бы что-нибудь придумать и для случая когда это происходит НЕ во время скринсэйвера :-)

    так как badUSB вероятнее всего как раз и должен использоваться во время НЕ скринсэйвера.

    ну и конечно Chrome OS не нужна -- пусть для Linux что-то изобретают

     
     
  • 3.4, AnonPlus (?), 22:56, 24/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А речь не о том, когда оно ИСПОЛЬЗУЕТСЯ, а о том, когда оно ВОТКНУТО.

    Нсли оно ВОТКНУТО во время скринсейвера, то оно не будет использоваться ни во время, ни после окончания скринсейвера. А ВТЫКАЮТ как раз, когда юзер отсутствует физически на месте.

     
     
  • 4.7, iPony (?), 04:54, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А ВТЫКАЮТ как раз, когда юзер отсутствует физически на месте

    Ну есть же ещё «о кто-то забыл флешку, надо посмотреть что там».

     
     
  • 5.11, Xasd5 (?), 10:44, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну есть же ещё «о кто-то забыл флешку, надо посмотреть что там».

    badUSB это не о том.

    это когда воткнул usb-флешку, а она ещё и в добавок оказалсь usb-клавиатурой (сама нажимающая свои клавиши)..

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

     
     
  • 6.13, iPony (?), 10:49, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И о том в том числе. Что-то вообще как-то мимо...

    https://ru.wikipedia.org/wiki/BadUSB

     
  • 4.15, J.L. (?), 12:59, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А речь не о том, когда оно ИСПОЛЬЗУЕТСЯ, а о том, когда
    > оно ВОТКНУТО.
    > Нсли оно ВОТКНУТО во время скринсейвера, то оно не будет использоваться ни
    > во время, ни после окончания скринсейвера. А ВТЫКАЮТ как раз, когда
    > юзер отсутствует физически на месте.

    а что, включение "флешки" (логических линий, а не линий питания) по таймеру, а не только в момент подачи питания - не комильфо?

     
  • 3.10, Аноним (10), 10:12, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > неплохо было бы что-нибудь придумать и для случая когда это происходит НЕ во время скринсэйвера

    да. А еще: неплохо бы вынести железные тумблеры для usb, микрофона, камеры, кардридера, возможно, клавиатуры и тача - что бы юзер наглядно видел, что у него включено, и собственными руками включал и выключал, то, что считает нужным. И ввести это в стандарт индустрии всех девайсов.

     
     
  • 4.12, Xasd5 (?), 10:47, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > железные тумблеры для usb

    тут не тумблеры нужны, а переключатели режимов (на каждом из usb):

    * режим накопителя
    * режим устройства ввода
    * режим можема
    * ну и ещё что там за режимы могут быть

     
  • 4.19, Crazy Alex (ok), 17:09, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И зачем? Если вы не доверяете своему софту - то поздно дёргаться. А если доверяете - то и софтовых хватит.
     
  • 3.17, Аноним (17), 13:53, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > неплохо было бы что-нибудь придумать и для случая когда это происходит НЕ во время скринсэйвера :-)

    В Grsecurity/Pax был файл в procfs, после записи в который ядро начинало игнорировать вновь подключаемые по USB устройства до следующей перезагрузки.

     
     
  • 4.20, Crazy Alex (ok), 17:10, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну, эти удобно в принципе сделать не способны. "До перезагрузки", это ж надо придумать
     
     
  • 5.24, Аноним (24), 20:42, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это by design. Всё, что можно подключать, подключается при включении. Владелец/пользователь обязан физически присутствовать рядом с машиной во время запуска.

    И нужно помнить, что эта мера может быть не только и не столько против BadUSB, сколько против подключения несанкционированных носителей и выноса секретной информации.

     
     
  • 6.25, Crazy Alex (ok), 00:09, 26/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Именно, у них by design - это "безопасно - и ладно, и пофиг, какой ценой". Будь это падение быстродействия, ломка совместимости или банальное неудобство.

    Насчёт защиты секретной информации мне тема не близка совершенно, но полагаю, что это очень частный случай и надо быть психом, чтобы делать решение только под него. BadUSB - куда более понятная и распространённая угроза.

     
  • 3.28, Аноним (-), 00:41, 26/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А для Linux, в Qubes давно есть защита от такого.
     
  • 2.14, Онанимус (?), 11:21, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Правильный подход!

    Товарищ майор не одобряет вас!

     
  • 2.30, Аноним (30), 14:47, 28/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Пацаны вообще ребята!
     

  • 1.2, A.Stahl (ok), 22:01, 24/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Who cares?
     
  • 1.6, Аноним (6), 23:09, 24/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Любо.
     
  • 1.8, Какаянахренразница (ok), 08:00, 25/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ну, воткнул я злой девайс, пока хозяина не было. Ну, не активировался он сразу. Девайсы нынче маленькие. Хозяин подойдёт, разблокирует свой кампуцер и даже не заметит как активируется мой девайс.

    [Дисклеймер про исследовательские цели, отказ от ответственности, свой страх и риск и про не повторять дома]

     
     
  • 2.16, Аноним (17), 13:50, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Хозяин подойдёт, разблокирует свой кампуцер и даже не заметит как активируется мой девайс.

    Он не активируется, если был подключён во время неактивности. Придётся вытащить и вставить заново на глазах изумлённого хозяина.

     
     
  • 3.21, Аноним (21), 17:12, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лол зачем ?

    Питание на портах будет скорее всего, просто по таймеру передергивать само устройство раз в минуту (если нет ответа от ос )

     
     
  • 4.27, Crazy Alex (ok), 00:22, 26/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Именно, можно ещё и device id менять - хоть из списка распространённых, хоть как. Если атака целевая - то узнать device id используемых "клиентом" аксессуаров - задача совершенно тривиальная.
    И всё, больше никакой общей механики идентификации в usb нет.
     

  • 1.9, Аноним (9), 09:17, 25/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    USB модем
     
  • 1.18, vantoo (ok), 16:59, 25/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сразу вспомнился рассказ о хакере и солонках.
     
  • 1.22, Crazy Alex (ok), 17:22, 25/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Бестолковая попытка заткнуть дыры протокола. Наверняка обнаружится масса кейсов, где этот номер не пройдёт.

    Либо реализовывать нормально (хм, интересно, что там в планах у USB Консорциума на этот счёт) - "безопасный режим" с идентификацией по ключу, хранимому на устройстве вплоть до аналога иерархии доверия, разрешение только определённых режимов и т.д. - либо не делать ничего. А так - создание иллюзии безопасности, не более.

     
     
  • 2.23, a (??), 17:52, 25/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, навертим лишней мути, в реализациях которой будут дополнительные дыры в безопасности.
    Crazy Alex, ник очень в тему ;-)
     
     
  • 3.26, Crazy Alex (ok), 00:16, 26/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Альтернатива - каждый пытается навертеть своё, хоть как-то сохраняя совместимость с системами, которые про все эти меры ни сном ни духом.
     
  • 2.29, J.L. (?), 13:34, 26/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Бестолковая попытка заткнуть дыры протокола. Наверняка обнаружится масса кейсов, где этот
    > номер не пройдёт.
    > Либо реализовывать нормально (хм, интересно, что там в планах у USB Консорциума
    > на этот счёт) - "безопасный режим" с идентификацией по ключу, хранимому
    > на устройстве вплоть до аналога иерархии доверия, разрешение только определённых режимов
    > и т.д. - либо не делать ничего. А так - создание
    > иллюзии безопасности, не более.

    вроде бы юсб (и 3 и C) не дают подключенному устройству никакого прямого доступа в память или ещё к каким ресурсам системы кроме как к питанию?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру