Perfect Direction – ASW #182

Here's a local privilege escalation flaw that's been lurking -- but not unnoticed -- since its introduction in May 2009. The story opens up several discussion topics about bugs, vulns, exploits, and code correctness. In December 2013 a researcher noted this NULL argv[0] behavior, but didn't have a clear exploit scenario (https://ryiron.wordpress.com/2013/12/16/argv-silliness/). This write up even notes that some binaries have explicit guards against this behavior (i.e. argc == 0, which would lead to NULL argv[0]). So, it's interesting to see why and when programmers choose to harden their code against flaws, assume correct behavior, or rely on implicit behaviors as controls against security issues. Now in January 2022 Qualys researchers have demonstrated how to reliably leverage environment variables as part of a reliable privilege escalation against this bug, clearly showing that it's a flaw with security consequences. Looking back at the manual pages for exec(3) and execve(2), we also find the kind of language that leads to this kind of ambiguity between design, implementation, and intention. From the exec(3) notes, "The first argument, by convention, should point to the filename associated with the file being executed." From the execve(2) notes, On Linux, argv and envp can be specified as NULL. In both cases, this has the same effect as specifying the argument as a pointer to a list containing a single null pointer. Do not take advantage of this nonstandard and nonportable misfeature!" Even though the documentation offers warnings on how to handle this edge case, it's still seems to be failing developers by not having a more strict, opinionated default. This is the kind of thing where a software package is vulnerable in one environment (e.g. Linux), but not others. For example, the Qualys article notes "that OpenBSD is not exploitable, because its kernel refuses to execve() a program if argc is 0." -- OpenBSD is one of those strongly opinionated environments and in this case benefited from that stance. References - https://www.man7.org/linux/man-pages/man3/exec.3.html - https://www.man7.org/linux/man-pages/man2/execve.2.html

We're turning attention to some crypto (as in cryptocurrency) attacks again this week. Most notably because they combine a programming error that's completely unrelated to memory safety and the consequences have demonstrable dollar impacts. Check out the technical write up at https://certik.medium.com/qubit-bridge-collapse-exploited-to-the-tune-of-80-million-a7ab9068e1a0 The technical article is a well written stroll through four steps to take advantage of a very simple (in retrospect) logic flaw. Essentially, an attacker could withdraw tokens from a smart contract without depositing any in the first place. The article walks through the assumptions behind this deposit() function, why existing checks failed to account for this scenario, and how an attacker could abuse it. If you want examples of insecure programming that don't involve memory safety issues, this is a great one to read. It highlights the importance of concepts like failing secure, handling errors, and the complexity of verifying the transitions within state machines -- the sorts of thing that any piece of software must deal with.

Here's another article for this week's venture into cryptocurrency misconducts and miscalculations. It's another example of code that's written in a memory safe language still requiring safety in other domains -- like logic. Check out the technical write up at https://media.dedaub.com/phantom-functions-and-the-billion-dollar-no-op-c56f062ae49f The attack hinges on "phantom functions". As the article notes, "A contract with a phantom function does not really define the function but accepts any call to it without reverting." It walks through the implementation mistakes in the smart contract as well as the changing assumptions around fallback functions. Older code apparently encountered it often and knew to implement them, new code apparently skips them, leaving room for these phantom functions to be abused. The article poses a key question that should be part of any appsec code architecture discussion, "The problem is, what if the undefined function is relied upon for performing important security checks?"

This is the kind of article we highlight for its combination of clever hack (it earned a $100K bounty, after all), setting up context and background for the reader (including acknowledging others' works), and persistently pursuing a feature in order to discover a security flaw. The flaw comes from a chain of events starting with custom URL schemes, diving into details of web archives, bypassing security assumptions, and achieving success because an allow list based its decision off a reference to content rather than the content itself. Check out the technical write up at https://www.ryanpickren.com/safari-uxss and the BlackHat presentation it references at https://i.blackhat.com/eu-20/Thursday/eu-20-Zhou-Cross-Site-Escape-Pwning-MacOS-Safari-Sandbox-The-Unusual-Way.pdf

Here's a seed for discussion on typed vs. untyped languages or the benefits of enforcing strict types. While the article itself doesn't have specific examples of security boundaries or controls falling due to Python's coercion of types due to the fact that "NaN becomes extremely greedy" -- it's a phrase that makes us wish for a crime series about an English grandmother turned elite hacker who targets banks worldwide. It's also reminiscent of the SQL injection WAF bypass we covered last year from the article, https://www.gosecure.net/blog/2021/10/19/a-scientific-notation-bug-in-mysql-left-aws-waf-clients-vulnerable-to-sql-injection/

I hesitated adding this article since it's light on details about the underlying flaw. All we know is that it's an RCE, which makes for a far more dangerous PVP. But what's more PVP than slinging RCEs back and forth? For a more appsec oriented style of PVP, check out the OWASP list of vulnerable applications and CTFs at https://owasp.org/www-project-vulnerable-web-applications-directory/

Another container escape. What's interesting here is the docker default seccomp profile will filter this out, but k8s still hasn't managed to put a default seccomp profile in place...