-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tiny-http Request Smuggling #355
Add tiny-http Request Smuggling #355
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the report! I've left one nit, other than that LGTM
date = "2020-06-16" | ||
title = "HTTP Request smuggling through malformed Transfer Encoding headers" | ||
url = "https://github.com/tiny-http/tiny-http/issues/173" | ||
categories = ["format-injection"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think "format injection" is quite correct; we do not seem to have a proper category for this.
I suppose we should eventually transition to CWE, but in the meanwhile it's probably best to just drop the category field here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah agreed, this is an injection vulnerability, but the format-injection
category is more precisely intended for "format string injection" vulnerabilities.
Also agreed it'd be nice to implement CWE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, CWE would be nice
@Shnatsel, I'm sorry if this is a dumb question, but are there recommendations for what to do with a vulnerability before it gets a non-zero number? I got a local |
@scooter-dangle I've fixed this -- it was a bug that this was assigned 2020-0000, it should have been assigned 0000-0000 so our auto ID assignment script noticed it. |
Thanks, @alex! |
…0.1.20 I believe these two vulnerabilities were patched at 0.1.20. For RUSTSEC-2019-0033: The advisory links to the bug: hyperium/http#352 In that bug, the fixing PR was hyperium/http#360 That PR merged the commit 81ceb61 to fix the bug; that commit, according to GitHub, was first picked up by tag v0.1.20 ([commit][1]). [1]: hyperium/http@81ceb61 For RUSTSEC-2019-0034: This advisory is two separate GitHub issues against `HeaderMap::drain`, http rustsec#354 and http rustsec#355. For the first: the issue: hyperium/http#354 In that bug, the fixing PR was hyperium/http#357 That PR merged the commit 82d53db to fix the bug; that commit, according to GitHub, was first picked up by tag v0.1.20 ([commit][2]). [2]: hyperium/http@82d53db For the second: the issue: hyperium/http#355 In that bug, the fixing PR was hyperium/http#362 That PR merged the commit 8ffe094 to fix the bug; that commit, according to GitHub, was first picked up by tag v0.1.20 ([commit][3]). [3]: hyperium/http@8ffe094
Reopening this to add the RustSecDB, initially was hoping for a patch before making this into an advisory