On Tue, Feb 03, 2004 at 04:30:35PM -0800, Rick Moen wrote:
> Quoting Colm MacCarthaigh (colm at stdlib.net):
> > On Tue, Feb 03, 2004 at 10:01:22AM -0800, Rick Moen wrote:
> > > This is why we sysadmins teach people to say "/bin/su" when su'ing to
> > > root. Eh, you never learned that? Sorry to hear.
> > Exec to a new shell that ignores that, whatever, it doesn't matter.
>> Mercy me, which MUA not only execs a new shell, but then attempts to run
> su from it? Please let us know.
Thus far, I have not made single comment regarding MUA's. I have taken
issue with just part of what you had to say, which I would wager was
pretty clear to everyone else. Although you probably have a guide to
it somewhere on your website, it's worth reminding you that when a
person snips - they really are not concerning themselves with that content.
So if you trace this back up with your mailer, which no doubt supports
threading, you'll find I took issue with your "local root escalation"
statement. The circumstances under which the "exploit"  would be
ran were already presented (a theoritcally foolish MUA). My bone
is with the "cracks root" part - something you handwave out of the way
- but which I assert is commonly a relatively trivial process.
So please, don't try the old change-the-argument trick, we know you're
clever enough to keep track.
> > The principle remains the same, once you have compromised a root
> > holders account, root is next, in pretty short order. It's not hard,
> > there are many many trivial ways.
>> Your hand waves have just gotten about an order of magnitude more vague.
I've given you undeniable categorical examples, including some I've
successfully used. You don't seem to like either generalities or
But if you'd like a reference example, I'll restate (no doubt boring
most readers at this stage). Imagine a simple binary that is run
by a user (say they have a theoritcally broken MUA, or you trojan
it somewhere else):
1. Copies itself to a writable/executable location
2. determines what shell you're running
3. adds a line to then end of your shell profile to exec itself
4. proxies your shell commands, waits for you to use [insert
favourity way to su here]
5. Nabs the password
This isn't just doable, it's been done. I've done it, and I'm nowhere
near the first on the list. One could say it's common. Other approaches,
which I've already cited include monitoring memory, using LD_PRELOAD
or attaching tracers.
My core point being - if you can get a user to run a binary once,
you can own their account incredibly easily. If they are a root
holder, you'll typically be able to get root in a very short order.
And all that without a single local vulnerability in sight, you
just have to get a root-holder to run an untrusted binary (a
circumstance I'll remind you - this theoritical MUA pre-supplies).
So, to once again summarise - all you need is a dodgy MUA, and a root
holder using it (not untypical of a desktop linux user) and you're
set. No need for this not-entirely-unmaintained nonsense.
 Calling it an exploit isn't entirely accurate, since all it
exploits is human stupidity. Everything else - standard unix
Colm MacCárthaigh Public Key: colm+pgp at stdlib.net
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!