Pyra: USB Serial port security

[foobar]

I was just wondering... considering that there's been USB chargers spotted in the wild that were used to exploit devices connected to them, and the same port is meant to double as a serial port, do any security issues arise?

Or, more concretely: I hope that thing is output only. At least from bootup until root changes it. That would at least address any security concerns to sensitive things leaking into the kernel log, which they shouldn't, anyway.

Also, prompting for upper and lowercase letters that can be easily confused, in a Captcha, is evil.

 

[Wally]

It's a niche device. Nobody is likely going to design a USB charger to exploit the Pyra.

 

[WizardStan]

It isn't a USB port, it's a USB->serial device. It's also for debug output, though in theory you could set up a full shell on it, and then your security is as good as the shell security, which is probably at least as safe as your network security, meaning you're more likely to be hacked over the internet.

So you've got two things working against a hack: it's not a USB port so any hacks that may happen are going to be wildly different from these previous "charger is a hacker" things; and as Wally says, niche device that someone would have to actively try and exploit and really who is going to do that for such an incredibly low chance of payoff?

 

[dflatline]

Maybe it's best not to just go around putting random things in random holes with no protection; thats how you get STDs.

 

[Granitehead]

There are USB condoms.

 

[levi]

So you've got two things working against a hack: it's not a USB port so any hacks that may happen are going to be wildly different from these previous "charger is a hacker" things; and as Wally says, niche device that someone would have to actively try and exploit and really who is going to do that for such an incredibly low chance of payoff?

To be exact, as I understand it it is a USB port, just not one that's designed to look for and automount any mass-storage devices. Instead it implements the CDC interface (at a guess) to transmit (and receive) serial data. It's conceivable there's a hack out there against the USB base code, which would apply to this port as well as other USB ports, though I don't know of one to be fair, and it would probably have to rely on holes in the driver implementation, so we wouldn't get mac or windows attacks. And presumably we'd be able to turn it off in software if we wanted to.

 

[rygD]

To be exact, as I understand it it is a USB port, just not one that's designed to look for and automount any mass-storage devices.

The MicroUSB charging port reports itself as TTY USB device when connecting to a PC and you get your serial output there.

Edit:  Actually, now I don't know how useful that quote is.

 

[Binky]

I thought there was a hardware USB-serial converter (from FTDI or their ilk) wired to a hardware serial interface on the SOC?

 

[TrashyMG]

I thought there was a hardware USB-serial converter (from FTDI or their ilk) wired to a hardware serial interface on the SOC?

On the Devboard there is an FTDI chip handling the debug port.. Not sure if GTA04 went with that exact chip or not with the Pyra. 

From the OMAP5 EVM Manual:

2.9 Debug UART Interface

The OMAP5432 EVM provides a dual-port USART device (FTDI part number FT2232HQ). This provides

up to two UART terminal interfaces out via a single USBOTG micro-AB connector located at J14. Driver

software to utilize this device must be downloaded from the FTDI website. The first (lowest numbered)

port of this device is connected to UART3 from the OMAP5432 ES2.0 processor, while the second port is

unused. There are voltage translators provided to convert the 1.8V logic level UART signals to/from

OMAP5432 ES2.0 to the 3.3V signals required by the USART.

 

[mcobit]

If you want to integrate an ftdi chip, be sure to get a genuine one. They didn't make themself any friends by bricking chips with a driverupdate recently if they were ripoffs.


So be careful when sourcing them or use alternatives. Might be better anyway not to use ftdi after what they have done and how they reacted to complaintd about it imho.

 

[TrashyMG]

Yeah this has been a big deal, http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/

I agree mcobit, I'm afraid there may be shady part vendors trying to offload these potentially fake chips for real cheap.. And lower costs would look appealing to a small project like this.

 

[mcobit]

There seem to be some cheap alternatives though.


http://hackaday.com/2014/12/02/finding-a-cheaper-usb-to-serial-chips/

 

[Binky]

The first priority should be that whatever gets used "just works", I think.

There's nothing more stupid than having to mess around with drivers for a serial device.

Having said that, I'd rather not use FTDI parts if possible, owing to their appalling disregard for end-users.

Apparently, they only care about big customers with the resources to monitor the supply chain from chip fab to PCB population

 

[slaeshjag]

There's plenty of other chips woth not-so-evil-drivers. I personally have good experience of PL2303HX, but I've only used it on linux.

 

[Granitehead]

There are USB condoms.

It would be more effective (cost, practical) to just cut the I/O leads and leave the +/- entact.Another connector to put on a connector so you can be disconnected while you're connected?

You can also just cut your vas deferens instead of using a condom, much more practical, isn't it?

(Hint: But you may not want it. On top of that, you may still get STDs. The metaphor even works like this too: You can still fry the device with too much voltage even with cut data leads, but if you use a proper protection dongle with over-voltage and -current protection then you are safe no matter what)

 

[rygD]

Shouldn't this thread be in the Pyra section?

 

[WizardStan]

The Pyra section doesn't have a "guest" area.

 

[levi]

To be certain, there is still the potential for a hack. A serial connection is by default bidirectional, and a CDC/TTY connection definitely is, so it's worth asking if anything can be sent to the chip. I'd assume it won't be running a login shell or anything like that, just blindly sending out debug data, possibly in an interactive manner. Anything that crashed that, and took over the chip would have to be very targetted.

To be honest, if anyone wanted to infect someone's Pyra it's possible (look at stuxnet infecting nuclear centrifuges for example), but there are much easier avenues into the Pyra than that serial port. I'd have thought a dodgy file on the repo or a hack to the IP stack would have been more obvious avenues, and then whatever payload is likely to remain hidden for as long as possible, so not be the sort of nasty that nukes all your data instantly.

Of course, the Pyra like the Pandora is a full linux computer, so non-targetted linux viruses could infect it (although they'd have to be compiled for armhf, if they're not using an interpreted language). It's worth asking how the USB serial port is set up, if that means we can rule it out when considering any attack scenarios, but it's not the first route you'd be looking at after an attack anyway.

 

[Binky]

Also, if the attacker has physical access to your computer, you haven't really got a hope.

Its more worth worrying about remote attackers and being careful with network security.

 

[DrHAX]

On