I'm trying to learn about UART and related problems and solutions.
IIUC, UART is a hardware, RS232 is an interface and hyperterminal is a program. Would these parts be able to work together?
I asked a knowledgable professor in CS who illustrated it with an application use case where I understood some but not all.
I attach the illustration of the description where I understand some but not all.
I want to understand it all. Please correct me if I'm wrong
Why is a message-queue relevant? It looks like an array of msg?
Why is S (memory size) relevant?
Why is the difference between DMA and MMI relevant? Is it because DMA bypasses the CPU and therefore the CPU can't be relied for security?
Is ETH ethernet and could be via UART or only UART? Is the hyperterminal and standard i/o and tty examples of UART?
I will read more online sources of course.
K means a key file that should not be accessible and the ethernet connection, IIUC, is example of peripheral connection via UART.
P is supposed to mean a pointer. I vaguely hypothesize that it's about getting a pointer to a part of the RAM that is supposed to be secure.
Can you help me understand?
Answer
RS232 is an electrical and connector specification for how the voltages are interpreted as 1 or 0, and how they are connected, nothing more.
A UART essentially does the parallel to serial conversion and adds (and strips) some usually fairly minimal amount of framing around the (usually) bytes it sends, its interface to the processor is usually a memory mapped register and an interrupt or polling, DMA as such would be uncommon but possible, uart serial is usually just not that quick. There is nothing that requires either that RS232 be async serial from a UART (But it usually is) or that a UART ultimately drive RS232.
Hyperterminal is a program that can be configured to talk to a serial port, but you cannot assume that is the only attack vector.
The place you will find software vulnerabilities is in the higher levels of whatever protocol you are carrying over the RS232 link, for example you might be carrying TCP/IP encapsulated as SLIP over that link, which is a huge attack surface even if the high level application is something simple. The UART and the dozen or so lines of code that read bytes and stuff them into the rx ring buffer is seldom the problem, it is all the complex stuff that happens afterwards. Best case, I can convince some of the higher level stuff to crash, possibly the developer has left an assert on with the dump set to the serial port... Game on!
For hardware vulnerabilities, I would be thinking side channel attacks, either looking at noise on the signal lines (Can be used to estimate processor power consumption, which with poorly done crypto can leak key information). Possibly I might be able to abuse an input protection diode to force the power supply for the processor out of tolerance, maybe I learn something useful.... Maybe I can apply some RF to the serial port and get a crash that way, maybe I apply RF, sense the leakage on the supply wires and find that it is phase modulated in a way that leaks information, lots of things to try. Been there, done that.
You may find a talk given at 29C3 by Timo entitled "Milking the digital cash cow" interesting (It is on youtube as well as in the CCCs archives) as it demonstrates a side channel attack in the real world.
No comments:
Post a Comment