Tony <mts.spb.suxx@mail.ru> wrote:
On 15 Oct 2004 18:11:09 GMT, Frank Liu <> fliu@usdjmp1.eng.vodafone-us.com> > wrote:
by the way, mario is correct that QSS doesn’t really care much about security
probably because
- they think everyone on the box should be root anyways.
- the box is in an isolated environment anyways.
http://xforce.iss.net/xforce/xfdb/9341
Thes above link scares me to death…
Well, from looking at the link, it says:
" By passing an overly long string to one of the affected binaries, a
local attacker could overflow a buffer and execute arbitrary code on the
system with elevated privileges."
The only program in that list which is setuid root is sample – the rest
are not. If they are not setuid root, then if you overflow a buffer,
you can get the program to crash – or maybe even execute your own code,
but you can not get “elevated privileges” from it.
The one that is setuid root, sample, is a development system tool for
doing application profiling, and should not be in any shipped system.
As for getting a buffer overrun to actually execute some code, rather
than just crash, I’m not sure how you could do it. Nothing written to
the data space could cause this, as all the code is mapped into the
process read only. So, you’d have to know the buffer was on the stack,
and be able to over-write a stack return with an address somewhere else
in the stack, where you have the bad data. Might be possible in
theory – in practice, probably not an issue.
Now I can’t sleep knowing my boxes are about to be exposed to Internet.
If things like /bin/mkdir are vulnerable - what about /usr/ucb/Tcpip then?!
Sure mkdir can be made to crash – but it won’t give elevated
privilege. It starts out non-privileged, a buffer overrun won’t
give it privilege.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com