Re: Attack research on HTTP/2 implementations

IMHO, there is a limit in how far even the best pure specification
of DO/DONT's can go in creating perfect code. When developers
would be able to more easily read "how to build exploits against bad implementations"
before starting their implementation, i am sure that would go further
in creating better implementations than the best spec alone.

Maybe i am overlooking it, but i can not find a description of e.g.:
the H2.CL exploit in the HTTP/2 revision security section.

writing out exploits in security sections or add-on documents
(http2-bis and http2-break) will give coders also more ammunition
why good implementations cost more money (but also avoid more loss),
require more negative/exploit testing and ideally help coders to proactively
think about similar exploits and how to avoid them (extrapolation).

Once we're beyond this point and bad code is still written it
gets a lot more hairy and becomes an even bigger societal
problem. Instead of getting money from companies like Netflix
for reporting exploits as explained in your linked article, 
you might instead get sued as a security researcher even when
you comply with all well defined reporting procedures for security
weaknesses.  Just yesterday in Germany:

https://www.tellerreport.com/news/2021-08-05-criminal-charges-for-app-notice--cdu-germany-apologizes-to-security-researcher.B1GlL7EFJF.html

Her description of the exploit:

https://lilithwittmann.medium.com/wenn-die-cdu-ihren-wahlkampf-digitalisiert-a3e9a0398b4d

(explanatory screenshots are broken after you use google chrome translate).

Of course, this was the typical HTTP application exploit, which
leaves me with the fatalistic conclusion: Why even make HTTP secure
when HTTP application are going to mess up security anyhow *sigh*

Cheers
    Toerless

On Fri, Aug 06, 2021 at 10:43:00AM +1000, Martin Thomson wrote:
> https://portswigger.net/research/http2
> 
> The introduction claims to have found imperfections in the RFC, so I read this fairly carefully.  There's solid work here in terms of attacking implementations, but no concrete specification problems.
> 
> In terms of actual changes to specifications, the work we did in the HTTP/2 revision on field validation should already cover all of these attacks.  Not that RFC 7540 didn't, but we're a lot, lot clearer about it now.
> 
> There's a lesson in here for our industry regarding how implementations deal with untrustworthy inputs.  The thing we might each reflect on is why we haven't already internalized that lesson.  It's not like this is a new class of attack or anything.

Received on Friday, 6 August 2021 02:31:21 UTC