[Mauiusers] Maui LD_PRELOAD attack

Paul Millar p.millar at physics.gla.ac.uk
Fri Apr 11 05:05:00 MDT 2008


On Friday 11 April 2008 08:58:28 Miguel Ros wrote:
> > Maui (and presumably, moab) does not provide user-level authentication,
[...]
> Maybe I've misunderstood something, but I think that a similar level of
> security
> is what provides the Maui patch that I've sent to the list. It adds
> user-level
> authentication from a suid binary (mauth) that is not compiled by default.

Yes.  sorry, I was a little too brief there.

So, if I remember correctly, it works like this.  The "standard" configuration 
builds server and clients that use a "trusted clients" model.  Clients are 
trusted because they have access to a shared secret and use this shared 
secret to communicate with the server.

What is (seemingly) daft is, by default, the shared secret is compiled into 
the binary.  This means that anyone who can read any client can (in 
principle) know the shared secret.  Since all users must be able to read the 
binary image (to actually execute the code) this is a fundamental flaw in 
providing use-level security, as any user can obtain the secret and write 
their own client.

There's a couple of further mistakes that compound this:  the secret is an 
integer (by default, chosen by the RANDOM bash variable at build time), and 
is stored as a string within the executable.  This makes it easier to 
discover, but "fixing" these (by obfuscating the secret) just makes the 
problem a little bit harder.

So, to discover the shared secret, do:
	strings $(which mclient) |  grep ^[0-9]*$ | sort -n | uniq
The secret should be the last number.  There are more sophisticated methods of 
extracting this number, but they boil down to much the same thing: scanning 
the binary for the secret and extracting it.

Even if you can't easily discover this shared secret, one can fairly easily 
brute-force it, on average, within 10 hours (at the slow speed of 1 trial per 
second).  Depending on hardware, this could be done much more quickly.

Once you have this shared secret you can compile your own custom client with 
the secret embedded.  Alternatively, you can write a client that 
automatically scans a Maui binary to pull out the secret (this what I've 
done).

Perhaps easiest would be to compile a cooked version of the maui client that, 
for example, provides an extra command-line parameter: which user you would 
like to be.

Miguel, I've not studied your patch in detail, but if I understand the basic 
idea, your patch fixes this by protecting the shared secret with the system's 
file permissions: the secret then exists as a file rather than being embedded 
within the executables.  This, in effect, allows the sysadmin to vet code by 
switching on the suid bit: code that doesn't obtain the needed escalated 
privileges simply cannot read the share secret.

If I may make a friendly amendment: you should make the binary sgid rather 
than suid, specify a group (mauiclients) and have the shared secret read-only 
(chmod 2440) and owned by (for example) root:mauiclients.  This would prevent 
a privilege escalation exploit for mauth from allowing someone to altering or 
deleting the shared secret.

I'm not sure what mcsaDES does (DES-based hashing algorithm?), but (afaik) DES 
isn't considered secure anymore.  I'm guessing this could lead to known 
plain-text attacks.

HTH,

Paul.





More information about the mauiusers mailing list