News for hackers. Stuff that matters.
Re:BearSSL – Smaller SSL/TLS by pilif on Thursday November 03, 2016 @11:22AM (#12864703)
IMHO you're converting your heap buffer overflows into stack buffer overflows which are even easier to exploit.
Re:BearSSL – Smaller SSL/TLS by thenewwazoo on Thursday November 03, 2016 @01:54PM (#12866285)
Stack usage is also much, much, much easier to characterize. In systems where stack depth is well-controlled (i.e. most embedded systems that don't have dynamic process/thread creation), very simple analysis will suffice to identify places where you blow your stack.
Re:BearSSL – Smaller SSL/TLS by usefulcat on Thursday November 03, 2016 @02:05PM (#12866376)
Not using the heap != everything is allocated on the stack. In situations where you want to avoid dynamic allocation, memory for most things that would otherwise have been dynamically allocated ends up being statically allocated at compile time.
Re:BearSSL – Smaller SSL/TLS by sigjuice on Thursday November 03, 2016 @03:41PM (#12867265)
Absolutely none of this is immune to buffer overflows.
Re:BearSSL – Smaller SSL/TLS by usefulcat on Thursday November 03, 2016 @04:49PM (#12867816)
No, but you're a lot more likely to be able to overwrite the return address via a stack-based buffer overflow, and that is generally a much more serious kind of attack.
Re:BearSSL – Smaller SSL/TLS by revelation on Thursday November 03, 2016 @07:15PM (#12868960)
Exploiting systems without dynamic memory is pretty meh.. that's some NSA level Stuxnet bespoke shit.

But no, judging from the code, you just give it one big fat I/O buffer that will usually come from .bss

Re:BearSSL – Smaller SSL/TLS by nwmcsween on Thursday November 03, 2016 @07:58PM (#12869257)
It depends, does malloc have some form of hardening? does the compiler insert stack canaries?