[Mauiusers] Maui LD_PRELOAD attack
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
> is what provides the Maui patch that I've sent to the list. It adds
> 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
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
More information about the mauiusers