Continued attacks on HTTP/2

Posted Apr 15, 2024 12:22 UTC (Mon) by wtarreau (subscriber, #51152)
In reply to: Continued attacks on HTTP/2 by epa
Parent article: Continued attacks on HTTP/2

The problem is more about the practice and the way the language was taught rather than the language itself (others have the same limitations, starting from assembly). The problem is that when you're first taught programming, it's explained to you that if you go out of bounds, it will segfault and crash. And particularly since systems have been starting to ship with ulimit -c 0 by default, this has been perceived as the cheap error handling: why write a length check and go through error handling if the result is the same ?

What we need is computer teachers explaining first how to exploit a parser bug via a config file, a log line, a large HTTP header, etc so that early developers keep this in mind and never ever start with a bad habit. Laziness should not be an option. In parallel, compilers should make it easier to write correct code. For now they're doing the opposite, they're making it ultra-difficult to write correct code, forcing users to case, put attributes and what not to shut stupid warnings, so the simplest path to valid code is the least safe.

Continued attacks on HTTP/2

Posted Apr 15, 2024 12:47 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> And particularly since systems have been starting to ship with ulimit -c 0 by default, this has been perceived as the cheap error handling: why write a length check and go through error handling if the result is the same ?

When I was studying at a university about 25 years ago, we actually had a mandatory course where we wrote an exploit, with simple shell code, for a deliberately vulnerable server written in C. So people certainly know about the danger of OOB access.

Continued attacks on HTTP/2

Posted Apr 16, 2024 3:23 UTC (Tue) by wtarreau (subscriber, #51152) [Link]

That's great that you had this opportunity. The first time a person taught me about the ability to overflow a buffer and execute code 30 years ago, I almost laughed, and said "you'd be lucky if that would surprisingly work", and he told me "it works more often than you think". That's when I started experimenting with it and figured how hard it was to achieve on sparc (due to switched register banks) that I wrote a generic exploitation tool for this and finally managed to get root on some systems :-) I just felt sad that it was so much ignored by teachers themselves.

Continued attacks on HTTP/2

Posted Apr 15, 2024 13:30 UTC (Mon) by farnz (subscriber, #17727) [Link]

The person I worked with who was worst for writing code with security bugs was taught in exactly the way you describe; his attitude after graduating was that this was "just theory", and therefore he didn't have to care about secure handling of predictable errors since "it crashes, so we'll know if it's got a bug because we'll get bug reports". He was great at exploiting bugs, but useless at preventing them.

IME, the thing that helps you learn is to work in languages where you simply cannot write certain classes of bug without a compiler error; writing code that compiles in Agda is a lot harder to learn to do than writing code that C compilers will accept, but if you're used to thinking in terms of "how do I write this in a way that the compiler can see is bug-free?", you're better at writing code that is genuinely bug free, even when you then learn how to write C (albeit that you're also more likely to write a program extractor that takes your Agda, removes the proof-related bits, and outputs C).

Continued attacks on HTTP/2

Posted Apr 15, 2024 19:52 UTC (Mon) by epa (subscriber, #39769) [Link] (1 responses)

Even if it did reliably segfault and crash, that’s still not a good choice for a format parser run in-process as part of a larger application. Heck, even a command line tool would be considered buggy if it crashed on bad input instead of giving a helpful error.

Continued attacks on HTTP/2

Posted Apr 16, 2024 11:05 UTC (Tue) by paulj (subscriber, #341) [Link]

This was kind of the experience with the "wise" C network code I maintained. The parsers - as per other comments - were structured to use a simple, checking abstraction layer to read/write atoms. If the higher-level parser made a logical mistake and issued an out of bounds read or write, the checking layer would abort().

This solved the problem of buffer overflows. However, we would still generally have a DoS security bug from the process ending itself. Obviously, an abort() and possible DoS is still /way/ better than an overflow and RCE security bug, but also still not ideal.

The next challenge was to make the parsers logically robust. Memory safe languages do not solve this.

Explicit state machines, in languages (programming or DSLs) that can verify error events are always handled (e.g., by proceeding to some common error state) can help. And even C these days can trivially ensure that all events are handled in an a state machine. Requires programmer discipline though.

It's worth noting in this story (IIUC) that the implementations in "memory safe" languages were vulnerable to the bug, and implementation in the "unsafe" language was not. ;)