A good week?
This week my small collection of sysadmin tools received a lot of attention; I've no idea what triggered it, but it ended up on the front-page of github as a "trending repository".
Otherwise I've recently spent some time "playing about" with some security stuff. My first recent report wasn't deemed worthy of a security update, but it was still a fun one. From the package description rush is described as:
GNU Rush is a restricted shell designed for sites providing only limited access to resources for remote users. The main binary executable is configurable as a user login shell, intended for users that only are allowed remote login to the system at hand.
As the description says this is primarily intended for use by remote users, but if it is installed locally you can read "any file" on the local system.
How? Well the program is setuid(root) and allows you to specify an arbitrary configuration file as input. The very very first thing I tried to do with this program was feed it an invalid and unreadable-to-me configuration file.
Helpfully there is a debugging option you can add --lint to help you setup the software. Using it is as simple as:
shelob ~ $ rush --lint /etc/shadow
rush: Info: /etc/shadow:1: unknown statement: root:$6$zwJQWKVo$ofoV2xwfsff...Mxo/:15884:0:99999:7:::
rush: Info: /etc/shadow:2: unknown statement: daemon:*:15884:0:99999:7:::
rush: Info: /etc/shadow:3: unknown statement: bin:*:15884:0:99999:7:::
rush: Info: /etc/shadow:4: unknown statement: sys:*:15884:0:99999:7:::
The only mitigating factor here is that only the first token on the line is reported - In this case we've exposed /etc/shadow which doesn't contain whitespace for the interesting users, so it's enough to start cracking those password hashes.
If you maintain a setuid binary you must be trying things like this.
If you maintain a setuid binary you must be confident in the codebase.
People will be happy to stress-test, audit, examine, and help you - just ask.
Simple security issues like this are frankly embarassing.
Anyway that's enough: #733505 / CVE-2013-6889.
Syndicated 2013-12-29 14:59:55 from Steve Kemp's Blog