|
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-клавиатурой (сама нажимающая свои клавиши)..
а будь это во время именно Скринсэйвера -- ничего особенного не произошлобы кстати.
| |
|
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 - куда более понятная и распространённая угроза.
| |
|
|
|
|
|
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.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) не дают подключенному устройству никакого прямого доступа в память или ещё к каким ресурсам системы кроме как к питанию?
| |
|
|