- A quick walkthrough of how to crack hashed passwords with John the Ripper
- Password cracking wordlists reprise
- Crash course in Elasticsearch Logstash and Kibana log aggregation
- Fuzzing network services with Fuzzotron and Radamsa modified pcap testcases
- CVE-2019-15947 Bitcoin Core bitcoin-qt crash dumps contain wallets
A bash wildcard expansion to arbitrary command line arguments (globbing abuse) whitepaper
A lot of my research into bugs goes unfounded, and very seldom do I find a bug by actually looking for it, so much as it was just a typo or something. So when I realized that the wildcard character was actually a bash thing, and not the way that another called program parses arguments, it was because I accidentally typed * in a directory with a file I had accidentally generated somehow with xargs doing something unrelated. The file happened to have a dash in front of it, and that’s where things got more interesting.
Also note that setting
you’re paranoid should negate all this. Thanks Kerin Millar for this.
This is going to be a little different because I don’t have a use case where this can be abused yet to actually get local privilege escalation or anything yet, but it’s most obviously a bug, and I think it probable that in the wrong context could definitely break scripts that use wildcards, and even calling binaries that use silly things like bash -c. So my example is going to be a bit hypothetical, and this may be updated in the future when I find something it works on.
The basic gist of how it looks in the terminal is:
You can even type just * on the command line and the first file the globbing
routine spits out is going to be your command. It becomes obvious now that
bash globbing will let you add arguments to a command if you only can drop a file. So dropping a file called
--version is going to
make the called application show its version info. What if the scenario went
more like a cron job running as root:
Where part of
supersecure’s code is something like:
Then dropping a file called
--levelup in it’s working directory would copy
a suid 0 copy of
/tmp/lvl99, subsequently owning the system.
So as with our simplistic example, attacks like this are possible, though you may need to get creative with more than one file, etc. Once you can drop a file, you can let the “*” character’s expansion do the rest. I intend to update this if I find a real-world example of where this attack leverages local priv escalation.
It has been suggested that fixing this would break POSIX compatability, so stuff like this won’t be fixed in the future.
Thanks for reading, and happy haxxoring.