Electronics > Microcontrollers

Anyone here familiar with LWIP?

<< < (20/21) > >>


--- Quote ---DES/3DES is dead, dead, dead.  No need to even think about it.
--- End quote ---

Can one be 100% sure? There are loads of servers out there, hosting highly public stuff like PHP-BB communities, which have not been patched for 20 years. One I know got hit recently ;) The box I am doing is for industrial applications and that area is notorious for "it if works, leave it". Also after a few years the person who set it up has usually left and most coders (especially server-side - something I am quite involved with spec-wise and management-wise, although I don't do the actual config and coding) never document anything. It is only when something breaks because some certificate has expired that... there is panic. And money...

--- Quote ---Maybe this is easier said than done, but it seems like its time to get a debugger on it and see what the threads are doing when its hung.
--- End quote ---

You will have the last laugh. I did some GPIO waggle debug and found it was getting hung by TLS's filesystem reading of the certificates file. It was getting hung because the HTTP server also displays a file directory :)

FatFS obviously needs mutex protection for writing (FAT12 in this case) although it isn't obvious that a mutex is needed for reading (I have one though). Re-entrancy is an option on FatFS but if you enable it, you cannot run FatFS before the RTOS starts so e.g. you cannot read a config file which selects which RTOS tasks to run.

Another interesting point, for which I can't find a clear explanation, is related to FreeRTOS

#define configUSE_PREEMPTION    1
#define configUSE_TIME_SLICING  1

and whether the following is correct:

The RTOS is not pre-emptive on a time slice basis at the same priority, so a process which is just a loop will get nearly all CPU time unless there are higher priority tasks running.

The question is whether "same" is correct. I think if you have a load of tasks at priority 10, and all with a
while (true) {}
loop, the RTOS will switch them at 1kHz and each one will get 1ms. This behaviour was changed in FreeRTOS some years ago, from what I can find.

Obviously hanging like that is dumb and if you have nothing to do then
while (true)
is much better because the RTOS can move on right away. And it can run lower priority tasks too, whereas
while (true)
enables it to run same or higher priority tasks only.

Not quite LWIP but MbedTLS runs on top of LWIP, usually.

This turned up on the MbedTLS mailing list, and I am posting it here so somebody can have a laugh at the irony of "security" in the embedded sphere :)

To: mbed-tls@lists.trustedfirmware.org
Subject: [mbed-tls] security issue in mbedtls 3.30
From: Avi Epstein via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Date: Tue, 07 Mar 2023 16:02:22 -0000

security issue in mbedtls 3.30 in the release notes:

"An adversary with access to precise enough information about memory
accesses (typically, an untrusted operating system attacking a secure
enclave) could recover an RSA private key after observing the victim
performing a single private-key operation if the window size used for the
exponentiation was 3 or smaller. Found and reported by Zili KOU,
Wenjian HE, Sharad Sinha, and Wei ZHANG. See "Cache Side-channel Attacks
and Defenses of the Sliding Window Algorithm in TEEs" - Design, Automation
and Test in Europe 2023."

was this issue solved in this version?
mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org


--- Quote from: peter-h on March 07, 2023, 04:38:28 pm ---See "Cache Side-channel Attacks and Defenses of the Sliding Window Algorithm in TEEs"

--- End quote ---

I appears that this paper has yet to be published.  However, based on the abstract, the described attack mode has nothing to do with the class of processors being discussed here.  In particular, this is an attack against systems with Trusted Execution Environments (TEEs),  e.g. Intel SGX or ARM TrustZone.  And as with most such attacks, this one appears to be limited to situations where adversarial code is running on the target system itself, which is typically only seen in environments such as mobile phones and virtual machine services.  Monolithic embedded applications such as those that run on small STM32 parts are not subject to this mode of attack.

That said, side channel attacks (where secret data are leaked via seemly innocuousness means, such as EMF, power use fluctuations, or even sound) are very real and devilishly hard to avoid.  Indeed, the laptop you're reading this on is probably leaking all sorts of things right now: https://www.cse.wustl.edu/~roger/566S.s21/09065580.pdf.  Because of this, I believe that evidence of a side channel attack involving Mbed TLS is not really an indictment of IoT security as a whole as much as it is an indication of how hard security is in general.

You have to keep this in perspective, though.  It takes a lot of work to mount a practical side-channel attack against a monolithic embedded application.  And in most cases this requires close proximity to the victim device.  So side channel attacks generally are less urgent to defend against than, say, remote code execution attacks resulting from simple coding bugs.

Thast's an interesting paper (on the laptop stuff) but what happened to Van Eck? The old CRTs were great for that because the scan coils and grid drives generated tons of RF (I used to design CRT drive boards in the 1980s) and LCDs obviously work differently, but I am 100% sure you can recover a laptop screen image from a great distance.

I think most side channel attacks rely on knowing the structure of the software running on the machine. If open source, this is trivial, so if you have say Apache running on one VM on some server, you know where to look.

With embedded boxes, these are rarely open source so you have an uphill job right at the start. Key leakage is still possible (as you note, by supply current measurement, Vcc manipulation, etc, and smartcard chips are designed to resist that stuff, and you are free to put one of these in your IOT box if needed) but with no knowledge of the software, where do you start? Breaking the security fuse protection to start with, then disassembly...

But what makes me laugh is that there is no security whatsoever without physical security, and 99.9% of the time in the IOT sphere you have no physical security. Mostly, you can access the actual box, get into some boot loader or whatever, replace the TLS certificate store, and if you install a fake DNS server on the LAN then you are in.

There is stuff like secure Modbus, which is completely pointless since all interconnected boxes are usually on one LAN, with no physical security...

I would bet that for remote code execution to be viable it would need to be applied against known open source software which you know is used inside the box - such as LWIP or MbedTLS. But it would still be hard work, probably needing to be preceeded by breaking the CPU security and disassembling a load of code.

What does one do in applications where you do want secure comms for very good known reasons but you don't want a whole PC-like server in there? For example an electricity substation which you know is going to get remotely attacked by Russia? This is a decades-old problem which pre-dates modern over-internet hacking (look up the GI74 protocol). "IOT" is no good for that because the boxes are rarely if ever patched for security reasons. It is a good MbedTLS application - in theory but absolutely not in practice.

Would anyone know if LWIP or TLS heap manager has this bug


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod