Wstg: Section 4.8.14.3_Testing_for_Format_String has no valid whitepapers

[Zeerg]

Describe the issue
Section 4.8.14.3 has no valid whitepapers they all lead to 404s. We should track down some new ones.

[anantshri]

• Tim Newsham: “A paper on format string attacks”
  can be found in the way back machine (2005) (atleast its 404'ng since 2016 so a good spot)
  http://web.archive.org/web/20050321013937/http://comsec.theclerk.com/CISSP/FormatString.pdf

• Team Teso: “Exploiting Format String Vulnerabilities”
  seems to be archieved at https://www.win.tue.nl/~aeb/linux/hh/formats-teso.html

• Analysis of format string bugs
  same as one can be found in waybackmachine
  http://web.archive.org/web/20040801013516/http://julianor.tripod.com/format-bug-analysis.pdf

hope this helps
We should find new once but do the people feel those historical papers have important then we can keep a copy as archival on testing guide website.

[patrickceg]

I can try researching for new resources for this.

I use format strings a lot as a developer and know by experience they can be troublesome. In my workplace's codebase, I've seen our app crash due to bugs in the logging (with format strings) even though the algorithm that was being logged handled the invalid input just fine.

At the same time I can see what techniques there are to attack them and what I can flag in code review :)

[Zeerg]

I'm thinking

https://cs155.stanford.edu/papers/formatstring-1.2.pdf
https://www.win.tue.nl/~aeb/linux/hh/formats-teso.html
https://www.usna.edu/Users/cs/aviv/classes/si485h/s17/units/06/unit.html

[victoriadrake]

Thanks @patrickceg!

@Zeerg would you like to be assigned?

[patrickceg]

I'm going to keep notes in a Github GIST for now (which will mainly be a scratchpad of links) https://gist.github.com/patrickceg/f29eb27abe2dc770a62f00ea80288ac2

@anantshri @Zeerg I'm open to ideas as well: at this point I'm exclusively looking for articles regarding the tests for format strings (trying to limit my search to 2015 and newer), and after piling all of that up, we can see what we can do to update the article.

If we find enough "new" articles that essentially don't show any additional information or information that contradicts what's in the current version of the guide, we can change the links only. If the new resources also require updating the article, we can decide to make updates.

I'm interested to see if there are non C/C++ format string articles as well. While most languages (with properly patched interpreter / runtime anyway) won't allow you to enumerate the stack through a format string, linters for other languages (example: https://pylint.readthedocs.io/en/latest/technical_reference/features.html#string-checker ) do have rules for that language's version of the format string. At this point, I'm not sure how many of these would cause a security issue when presented a bad case while still work when presented a good case, hence my hunt for articles.

[patrickceg]

I'll have to look in to this a bit more, but I found a Python format string example from https://www.netsparker.com/blog/web-security/string-concatenation-format-string-vulnerabilities/ which could cause a Python web app to disclose more than what the programmer wanted about an object, but it wouldn't go in the buffer overflow section as the disclosure is not from an out of bounds memory read. (The disclosure instead comes from reading an attribute of the object that wasn't intended by the app developer.)

If I see more samples like this, it's possible that format string should be moved out of the "buffer overflow" section since non-C examples wouldn't fit under that topic.

[victoriadrake]

Thank you for the updates @patrickceg!

[patrickceg]

I think I have enough newer links to start changes with pull request being available in 1-2 weeks (because this will require multiple sittings to see how the old instructions and the new articles line up).

It looks like in non-C languages you can cause information disclosure but usually not buffer overflow. How would you like me to handle the change? Should I just do a quick update to the links, or should I add the section for the non-C language format string issues, which means the page's section won't be valid anymore?

[ThunderSon]

@kingthorin You think that maybe we should do something to the lines of how SQL injection is done/handled? Have a bigger topic (SQLi), and then create smaller tests that relate to it (NoSQL, MSSQL, etc.)?
I think this follows either each page follow a certain attack scenario. I was trying to see Client Side Testing .. I didn't feel that it covered all cases (Which is why it's put in the v5 outcomes :) ). You wanna have a call in the coming days to see how to tackle similar issues/points? Remembering from Mat, the format followed was based on a consensus by a group of people and feedback. Let's tend with this in a care manner. Let me know on Slack your availability.
All other feedback from anyone is welcomed as well 😄

[victoriadrake]

Maintainer's note: this will close #292.

I'm minded to nuke the whole section README page in favor of a table of contents listing, anyway. As we develop these topics, the categories that page proposes will become less relevant and more limiting. I guess that's my vote for #243.

@patrickceg I'd advise that you update the article with the information it deserves based on the scope of, "Testing for Format String" and not get bound up by sections. It sounds like you're doing great research and I wouldn't want to exclude valuable info because it didn't seem to match the (legacy) section. Thank you again for authoring this!

[patrickceg]

Update: I'm starting an outline (again in my GIST scratchpad https://gist.github.com/patrickceg/f29eb27abe2dc770a62f00ea80288ac2 ) to lay out what pieces of information I want in the new article.

It's essentially going to be a rewrite because even if I ignored the non-Java format string (or logging framework string) bits, it's surprising that the original article puts way too much emphasis on the main threat being a buffer overflow, almost ignoring the fact that you could also expose important information that isn't the stack pointer. (My local OWASP chapter held a hackathon where one of the objectives was to mess with a format string to expose an API key or password that was also on the stack.)

[kingthorin]

Thanks for the update, the outline is looking good to me.

[kingthorin]

Don’t let it get overwhelming, tackling this in steps will be easier to assemble and review. It doesn’t have to be one giant PR (unless that’s what you prefer for some reason of course).

[patrickceg]

I was planning to just leave a comment but the "draft pull request" button was easier to find than my commit 😄 I'm sure there's a whole lot of errors in there that I won't be able to see until later.

One issue I do know for this is the C/C++ tool I linked is ~4 or 5 years old (still an improvement over the one mentioned before, which was abandoned 15 years ago). If we can find a better tool, that would be great. The popular CPPCHECK doesn't look for string format append and I can't say much about the paid ones because their function is buried behind marketing material.