Fwd: [cros-discuss] Hacking possibility? Real or not?
freebsd at edvax.de
Tue Jun 20 20:04:18 UTC 2017
On Tue, 20 Jun 2017 11:15:58 -0400, James B. Byrne via freebsd-questions wrote:
> On Tue, June 20, 2017 06:38, Matthew Seaman wrote:
> > On 2017/06/20 10:23, Matthias Apitz wrote:
> >> In the mailing-list about Chromium OS is some interesting discussion
> >> about some attack vector using an USB plug-in with some Raspery
> >> system behind to offer to the OS an USB keyboard and ethernet and
> >> at the end take over the system. More of the discussion here
> >> https://groups.google.com/a/chromium.org/forum/?hl=en#!topic/chromium-os-discuss/UqbGh2kHaVw
> >> and the full technical description here:
> >> https://samy.pl/poisontap/
> >> As far as I can see, the same attack would be possible as well on
> >> FreeBSD, maybe not so easy because the devd(8) must be configured
> >> and the module for ethernet on USB cdce(4) must be loaded in advance.
> > Isn't this yet another manifestation of physical access to the
> > hardware being almost impossible to secure against? Don't plug
> > in any strange USB devices kids, and don't let your portable kit
> > out of your control so that other people could take liberties
> > with your USB ports either.
> Every USB device contains a controller which itself operates on the
> basis of flash-able microcode. Few such controllers have any
> safeguards against being reprogrammed. Consequently, any physical
> access to any USB port on a host allows an attacker to permanently
> corrupt and infect the USB device controller(s) on a target system.
> As such malware likely contains code to prohibit further reprogramming
> the infection is permanent and removal of the affected hardware is the
> only remedy. On most modern computers this requires discarding the
> This issue was demonstrated at BlackHat-2014.
I think you're refering to "BadUSB". For reference and context:
With physical access to a machine, no matter if via USB or
orhter means, it's more or less game over, and no OS mechanism
can prevent that. As Valeri mentioned, physical security always
is part of the game. ;-)
Regarding the initial submission, I think FreeBSD configuration
determines what happens when a new network device is being found
(even if it's just an emulated one). In "worst" case, the system
recognizes the interface and then does nothing - no DHCP request.
Thas "stops" the attack at this poing.
Everything else explained depends on the network functionality
being established. PoisonTap's primary operation is to act within
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions