There is new version (1.01) available for download.
http://members.home.com/kovalenko/software/spin-1.01.tgz
Changes include:
Enjoy,
Thanks Igor!
BTW, I have tried to re-compile SPIN to Neutrino 2.0C (PPC) … but
without success =:-( .
QNX6 and Neutrino 2.0C are not souce code compatible.
I don’t know in details all differences in the kernel calls and
related data structures … do you believe the a port should be
possible ?
I would be nice to have a tool like sac as available for QNX4.
Armin
Igor Kovalenko wrote:
There is new version (1.01) available for download.
http://members.home.com/kovalenko/software/spin-1.01.tgzChanges include:
- fixed problem with flickering (thanks Andrew)
- it will make sure it is running as root or setuid root to avoid problems
getting swap stats. You’ll have to install it as root therefore.- fixed memory leaks which somehow nobody noticed >
- changed makefile - ‘make install’ will put it into /usr/local/bin and set
SUID bit.Enjoy,
- Igor
First Igor, thank you for the great utility…I was missing ‘top’ and now
I have something better. Secondly, from a security standpoint, wouldn’t it
be better to just check uid and not display certain info if not root? I’m
paranoid enough to strongly dislike suid executables but I’d like users to
be able to run this program (albiet missing some info) as well.
Cheers,
Kris
Igor Kovalenko <kovalenko@home.com> wrote:
There is new version (1.01) available for download.
http://members.home.com/kovalenko/software/spin-1.01.tgzChanges include:
- fixed problem with flickering (thanks Andrew)
- it will make sure it is running as root or setuid root to avoid problems
getting swap stats. You’ll have to install it as root therefore.- fixed memory leaks which somehow nobody noticed >
- changed makefile - ‘make install’ will put it into /usr/local/bin and set
SUID bit.Enjoy,
- Igor
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
Kris Warkentin wrote:
First Igor, thank you for the great utility…I was missing ‘top’ and now
I have something better. Secondly, from a security standpoint, wouldn’t it
be better to just check uid and not display certain info if not root?
If it was sensitive information, yes. But the only reason why it has to
be root is to be able to show swap file usage statistics which hardly
can be considered a security hole. It does not update anything in the
system nor it accepts any input from outside which could be abused.
I’m
paranoid enough to strongly dislike suid executables but I’d like users to
be able to run this program (albiet missing some info) as well.
If you’re paranoid about security to any extent you should not be
running QNX in the first place
There are more secure systems as I argued many times in the past.
Besides, you have source and can always change it to suit yourself
Personally I think SUID bit is not dangerous for this particular
application. Certainly not more dangerous than for ‘swapctl’ utility
which needs SUID bit for the same reason. You’re running many other
programs with suid bit without even thinking about it.
Armin Steinhoff wrote:
Thanks Igor!
BTW, I have tried to re-compile SPIN to Neutrino 2.0C (PPC) … but
without success =:-( .QNX6 and Neutrino 2.0C are not souce code compatible.
I don’t know in details all differences in the kernel calls and
related data structures … do you believe the a port should be
possible ?
It might be possible but I’m not sure how useful would it be. The 2.0
was real mess and I can’t imagine why anyone would want to stick with it
anyway. Even Windows/Metrowerks customers will soon have 2.11 beta…
That said, there are problems running spin even on 2.11-PPC (although it
compiles fine). First, the tcgetsize() on PPC returns success but fills
rows & cols with 0. That makes SIGWINCH handling impossible, but you can
probably live with it. Then sending SWAP_STAT message to procnto-600
returns ENOTTY. There’s no swap of course but why such a bogus errno?
Next, there are problems with printf() - in some cases some bogus
symbols will be displayed and mess up the screen. I could make some
workaround of course…
Next update will be tested on PPC (MCP750) under 2.11beta and will
contain PPC binary as well. Can’t promice you 2.0 support, I simply
don’t have it anymore and not particularly inclined to re-install it. I
don’t even remember if it had support for mcp750 at all.
cheers,
I would be nice to have a tool like sac as available for QNX4.
Armin
Igor Kovalenko wrote:
There is new version (1.01) available for download.
http://members.home.com/kovalenko/software/spin-1.01.tgzChanges include:
- fixed problem with flickering (thanks Andrew)
- it will make sure it is running as root or setuid root to avoid problems
getting swap stats. You’ll have to install it as root therefore.- fixed memory leaks which somehow nobody noticed >
- changed makefile - ‘make install’ will put it into /usr/local/bin and set
SUID bit.Enjoy,
- Igor
I AM paranoid about security and I know that QNX is not the most secure beast
out there. We ARE getting better though. Our TCP/IP stack actually produces
random sequence numbers now… We’re getting more and more small devices
(that might be running QNX) attached to public networks and security is
becoming a bigger focus. It has to if you don’t want some script kiddie
h4X0r1ng your refridgerator. That’s why I wouldn’t every make something suid
root if there is an alternative. I think that just not displaying certain
information if the user is not root is a small price to pay.
Now I’m no expert on h4X0r1ng but just on a quick glance at the spin code,
doesn’t the _cmdname() call return an arbitrary path with length that
should be determined by pathconf()? You’re reading into a buffer of length
_POSIX_PATH_MAX (256) so could not that be overrun? Next thing you know
someone’s smashing your stack and you’re in a world of hurt. This may not
be exploitable but writing secure code is extremely non-trivial so I’m of
the opinion that nothing should be suid root if it’s possibly avoidable.
Of course, this is all just my opinion so that and $5.00 will get you a cup
of coffee at Starbuck’s. Unfortunately my ignorance generally outweighs
my experience so everyone feel free to flame me into submission.
Kris
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
Kris Warkentin wrote:
First Igor, thank you for the great utility…I was missing ‘top’ and now
I have something better. Secondly, from a security standpoint, wouldn’t it
be better to just check uid and not display certain info if not root?If it was sensitive information, yes. But the only reason why it has to
be root is to be able to show swap file usage statistics which hardly
can be considered a security hole. It does not update anything in the
system nor it accepts any input from outside which could be abused.I’m
paranoid enough to strongly dislike suid executables but I’d like users to
be able to run this program (albiet missing some info) as well.
If you’re paranoid about security to any extent you should not be
running QNX in the first place >
There are more secure systems as I argued many times in the past.
Besides, you have source and can always change it to suit yourself >Personally I think SUID bit is not dangerous for this particular
application. Certainly not more dangerous than for ‘swapctl’ utility
which needs SUID bit for the same reason. You’re running many other
programs with suid bit without even thinking about it.
- Igor
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
Kris Warkentin wrote:
I AM paranoid about security and I know that QNX is not the most secure beast
out there. We ARE getting better though. Our TCP/IP stack actually produces
random sequence numbers now…>
(that might be running QNX) attached to public networks and security is
becoming a bigger focus. It has to if you don’t want some script kiddie
h4X0r1ng your refridgerator. That’s why I wouldn’t every make something suid
root if there is an alternative. I think that just not displaying certain
information if the user is not root is a small price to pay.
Good to have at least one paranoic in QNX. May be you indeed will force
them into respecting security issues
Keep in mind though, stricter security is almost always inconvinience
for users. Depending on who your users are, what they are doing and what
environment they’re normally working in, annoyance and inconvinience
coming from stricter security might very well outweigh feeling of
safety.
In this case, not having swap usage would certainly be inconvinient
since one can’t see what the whole situation with memory is without that
data. Note that most users will be using system in ‘personal’ way and
they will be admins for themselves. Such people fall into 2 categories:
those always working under ‘root’ (presumably bad boys) and those
working under regular UID while using root only for administration
purposes (presumably good boys). Guess who will suffer if spin is not
SUID root? No good deed goes without punishment …
That said, next update will not insist on being root, although ‘make
install’ will still set SUID. That gives all security paranoid users
flexibility to choose for themselves - if you install it with SUID it
will be more convinient, if not - it will be more secure. I’m wondering
what majority of you will choose
Now I’m no expert on h4X0r1ng but just on a quick glance at the spin code,
doesn’t the _cmdname() call return an arbitrary path with length that
should be determined by pathconf()? You’re reading into a buffer of length
_POSIX_PATH_MAX (256) so could not that be overrun? Next thing you know
someone’s smashing your stack and you’re in a world of hurt. This may not
be exploitable
Current handling of SIGWINCH is ugly in the first place. And yes, it is
insecure if spin is SUID root, although if you get nasty and launch spin
using over 255 characters path you’ll more likely get SIGSEGV than hack
into your fridge. Problem with pathconf() is that it needs path and to
get path I apparently need pathconf
I will replace _POSIX_PATH_MAX with PATH_MAX (1024) since that is what I
originally meant anyway. I hope shell will choke before spin is launched
if someone will try to overrun that. And I’m still waiting for someone
to teach me how to handle SIGWINCH in ncurses…
but writing secure code is extremely non-trivial so I’m of
the opinion that nothing should be suid root if it’s possibly avoidable.Of course, this is all just my opinion so that and $5.00 will get you a cup
of coffee at Starbuck’s. >
my experience so everyone feel free to flame me into submission.Kris
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Kris Warkentin wrote:First Igor, thank you for the great utility…I was missing ‘top’ and now
I have something better. Secondly, from a security standpoint, wouldn’t it
be better to just check uid and not display certain info if not root?If it was sensitive information, yes. But the only reason why it has to
be root is to be able to show swap file usage statistics which hardly
can be considered a security hole. It does not update anything in the
system nor it accepts any input from outside which could be abused.I’m
paranoid enough to strongly dislike suid executables but I’d like users to
be able to run this program (albiet missing some info) as well.
If you’re paranoid about security to any extent you should not be
running QNX in the first place >
There are more secure systems as I argued many times in the past.
Besides, you have source and can always change it to suit yourself >Personally I think SUID bit is not dangerous for this particular
application. Certainly not more dangerous than for ‘swapctl’ utility
which needs SUID bit for the same reason. You’re running many other
programs with suid bit without even thinking about it.
- Igor
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
Kris Warkentin wrote:
I AM paranoid about security and I know that QNX is not the most secure beast
out there. We ARE getting better though. Our TCP/IP stack actually produces
random sequence numbers now…>
(that might be running QNX) attached to public networks and security is
becoming a bigger focus. It has to if you don’t want some script kiddie
h4X0r1ng your refridgerator. That’s why I wouldn’t every make something suid
root if there is an alternative. I think that just not displaying certain
information if the user is not root is a small price to pay.
Good to have at least one paranoic in QNX. May be you indeed will force
them into respecting security issues >Keep in mind though, stricter security is almost always inconvinience
for users. Depending on who your users are, what they are doing and what
environment they’re normally working in, annoyance and inconvinience
coming from stricter security might very well outweigh feeling of
safety.In this case, not having swap usage would certainly be inconvinient
since one can’t see what the whole situation with memory is without that
data. Note that most users will be using system in ‘personal’ way and
they will be admins for themselves. Such people fall into 2 categories:
those always working under ‘root’ (presumably bad boys) and those
working under regular UID while using root only for administration
purposes (presumably good boys). Guess who will suffer if spin is not
SUID root? No good deed goes without punishment …That said, next update will not insist on being root, although ‘make
install’ will still set SUID. That gives all security paranoid users
flexibility to choose for themselves - if you install it with SUID it
will be more convinient, if not - it will be more secure. I’m wondering
what majority of you will choose >Now I’m no expert on h4X0r1ng but just on a quick glance at the spin code,
doesn’t the _cmdname() call return an arbitrary path with length that
should be determined by pathconf()? You’re reading into a buffer of length
_POSIX_PATH_MAX (256) so could not that be overrun? Next thing you know
someone’s smashing your stack and you’re in a world of hurt. This may not
be exploitableCurrent handling of SIGWINCH is ugly in the first place. And yes, it is
insecure if spin is SUID root, although if you get nasty and launch spin
using over 255 characters path you’ll more likely get SIGSEGV than hack
into your fridge. Problem with pathconf() is that it needs path and to
get path I apparently need pathconf >I will replace _POSIX_PATH_MAX with PATH_MAX (1024) since that is what I
originally meant anyway. I hope shell will choke before spin is launched
if someone will try to overrun that. And I’m still waiting for someone
to teach me how to handle SIGWINCH in ncurses…
Shouldn’t you get a “KEY_RESIZE” when the terminal size changed?
I could be totally wrong, but, here is a good sample:
ftp://ftp.qnx.com/usr/free/qnx4/os/libs/ncurses-4.2-bin.tgz
Or get ncurses library from anywhere, check out the little sample
called test/view.c, it showes how to catch terminal size change
(with SIGWINCH or with KEY_RESIZE).
-xtang
- Igor
but writing secure code is extremely non-trivial so I’m of
the opinion that nothing should be suid root if it’s possibly avoidable.Of course, this is all just my opinion so that and $5.00 will get you a cup
of coffee at Starbuck’s. >
my experience so everyone feel free to flame me into submission.Kris
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Kris Warkentin wrote:First Igor, thank you for the great utility…I was missing ‘top’ and now
I have something better. Secondly, from a security standpoint, wouldn’t it
be better to just check uid and not display certain info if not root?If it was sensitive information, yes. But the only reason why it has to
be root is to be able to show swap file usage statistics which hardly
can be considered a security hole. It does not update anything in the
system nor it accepts any input from outside which could be abused.I’m
paranoid enough to strongly dislike suid executables but I’d like users to
be able to run this program (albiet missing some info) as well.
If you’re paranoid about security to any extent you should not be
running QNX in the first place >
There are more secure systems as I argued many times in the past.
Besides, you have source and can always change it to suit yourself >Personally I think SUID bit is not dangerous for this particular
application. Certainly not more dangerous than for ‘swapctl’ utility
which needs SUID bit for the same reason. You’re running many other
programs with suid bit without even thinking about it.
- Igor
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
Igor Kovalenko wrote:
Kris Warkentin wrote:
I AM paranoid about security and I know that QNX is not the most secure beast
out there. We ARE getting better though. Our TCP/IP stack actually produces
random sequence numbers now…>
(that might be running QNX) attached to public networks and security is
becoming a bigger focus. It has to if you don’t want some script kiddie
h4X0r1ng your refridgerator. That’s why I wouldn’t every make something suid
root if there is an alternative. I think that just not displaying certain
information if the user is not root is a small price to pay.
Good to have at least one paranoic in QNX. May be you indeed will force
count me in also 
when it comes to Internet, you can never be too paranoid. after all, the
sendmail and Apache guys learned that they were too naive…
them into respecting security issues >
Keep in mind though, stricter security is almost always inconvinience
for users. Depending on who your users are, what they are doing and what
environment they’re normally working in, annoyance and inconvinience
coming from stricter security might very well outweigh feeling of
safety.In this case, not having swap usage would certainly be inconvinient
since one can’t see what the whole situation with memory is without that
data. Note that most users will be using system in ‘personal’ way and
they will be admins for themselves. Such people fall into 2 categories:
those always working under ‘root’ (presumably bad boys) and those
working under regular UID while using root only for administration
purposes (presumably good boys). Guess who will suffer if spin is not
SUID root? No good deed goes without punishment …That said, next update will not insist on being root, although ‘make
install’ will still set SUID. That gives all security paranoid users
flexibility to choose for themselves - if you install it with SUID it
will be more convinient, if not - it will be more secure. I’m wondering
what majority of you will choose >Now I’m no expert on h4X0r1ng but just on a quick glance at the spin code,
doesn’t the _cmdname() call return an arbitrary path with length that
should be determined by pathconf()? You’re reading into a buffer of length
_POSIX_PATH_MAX (256) so could not that be overrun? Next thing you know
someone’s smashing your stack and you’re in a world of hurt. This may not
be exploitableCurrent handling of SIGWINCH is ugly in the first place. And yes, it is
insecure if spin is SUID root, although if you get nasty and launch spin
using over 255 characters path you’ll more likely get SIGSEGV than hack
Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…
into your fridge. Problem with pathconf() is that it needs path and to
get path I apparently need pathconf >I will replace _POSIX_PATH_MAX with PATH_MAX (1024) since that is what I
originally meant anyway. I hope shell will choke before spin is launched
if someone will try to overrun that. And I’m still waiting for someone
to teach me how to handle SIGWINCH in ncurses…
- Igor
but writing secure code is extremely non-trivial so I’m of
the opinion that nothing should be suid root if it’s possibly avoidable.Of course, this is all just my opinion so that and $5.00 will get you a cup
of coffee at Starbuck’s. >
my experience so everyone feel free to flame me into submission.Kris
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Kris Warkentin wrote:First Igor, thank you for the great utility…I was missing ‘top’ and now
I have something better. Secondly, from a security standpoint, wouldn’t it
be better to just check uid and not display certain info if not root?If it was sensitive information, yes. But the only reason why it has to
be root is to be able to show swap file usage statistics which hardly
can be considered a security hole. It does not update anything in the
system nor it accepts any input from outside which could be abused.I’m
paranoid enough to strongly dislike suid executables but I’d like users to
be able to run this program (albiet missing some info) as well.
If you’re paranoid about security to any extent you should not be
running QNX in the first place >
There are more secure systems as I argued many times in the past.
Besides, you have source and can always change it to suit yourself >Personally I think SUID bit is not dangerous for this particular
application. Certainly not more dangerous than for ‘swapctl’ utility
which needs SUID bit for the same reason. You’re running many other
programs with suid bit without even thinking about it.
- Igor
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
Xiaodan Tang wrote:
if someone will try to overrun that. And I’m still waiting for someone
to teach me how to handle SIGWINCH in ncurses…Shouldn’t you get a “KEY_RESIZE” when the terminal size changed?
I could be totally wrong, but, here is a good sample:ftp://ftp.qnx.com/usr/free/qnx4/os/libs/ncurses-4.2-bin.tgz
Or get ncurses library from anywhere, check out the little sample
called test/view.c, it showes how to catch terminal size change
(with SIGWINCH or with KEY_RESIZE).
Thanks!
I looked at the sample, it is fairly clear how to use SIGWINCH, but
KEY_RESIZE looks strange. It seems like they do nothing at all for it.
Comments just say ‘ncurses will repaint’
Rick Lake wrote:
Igor Kovalenko wrote:
Kris Warkentin wrote:
I AM paranoid about security and I know that QNX is not the most secure beast
out there. We ARE getting better though. Our TCP/IP stack actually produces
random sequence numbers now…>
(that might be running QNX) attached to public networks and security is
becoming a bigger focus. It has to if you don’t want some script kiddie
h4X0r1ng your refridgerator. That’s why I wouldn’t every make something suid
root if there is an alternative. I think that just not displaying certain
information if the user is not root is a small price to pay.
Good to have at least one paranoic in QNX. May be you indeed will forcecount me in also >
when it comes to Internet, you can never be too paranoid.
Nice to see ‘random sequence numbers’ in the TCP/IP stack … but
what’s about e.g. the missing cookie control of VOYAGER??
Some information on how blind accepted cookies can threaten your
privacy are available at
http://www.junkbusters.com/ht/en/cookies.html
Make a test using Voyager …
What about a ‘personal firewall’ … any plans?
Armin
Rick Lake wrote:
count me in also >
when it comes to Internet, you can never be too paranoid. after all, the
sendmail and Apache guys learned that they were too naive…
How’s talking about internet here? SPIN has nothing to do with it.
Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…
SPIN does not spawn arbitrary external programs, only itself. Are you
going to put machine instructions into command line starting spin? And
those commands would exec into shell, right? Hmm, this sounds scary. If
someone could do that then he’s probably be qualified enough to find
easier ways to break into QNX
Igor Kovalenko wrote:
Rick Lake wrote:
count me in also >
when it comes to Internet, you can never be too paranoid. after all, the
sendmail and Apache guys learned that they were too naive…
How’s talking about internet here? SPIN has nothing to do with it.
Kris Warkentin mentioned “public networks” in his post:
“…We’re getting more and more small devices (that might be running
QNX) attached to public networks and security is becoming a bigger
focus…”
I assumed he meant Internet.
Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…SPIN does not spawn arbitrary external programs, only itself. Are you
going to put machine instructions into command line starting spin? And
those commands would exec into shell, right? Hmm, this sounds scary. If
someone could do that then he’s probably be qualified enough to find
easier ways to break into QNX >
you never know how versatile those hackers can get until you get hit by
one
- igor
When you smash the stack, one is getting the program to execute ANY arbitrary
commands one wants…the program running is not the same as the original.
Either way, I wasn’t suggesting that it was exploitable, only that any program
which has interaction or input MAY be exploitable. If I wanted to overrun the
buffer I mentioned above, perhaps I could create an arbitrarily long path that
would crash the program and make sure that the boundary of the buffer has the
appropriate characters to execute the desired instructions. May not be
possible but then again, there’s a lot of buffer overrun exploits out there…
Kris
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
Rick Lake wrote:
count me in also >
when it comes to Internet, you can never be too paranoid. after all, the
sendmail and Apache guys learned that they were too naive…
How’s talking about internet here? SPIN has nothing to do with it.Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…SPIN does not spawn arbitrary external programs, only itself. Are you
going to put machine instructions into command line starting spin? And
those commands would exec into shell, right? Hmm, this sounds scary. If
someone could do that then he’s probably be qualified enough to find
easier ways to break into QNX >
- igor
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
“Rick Lake” <rwlake@SPAM.REDIRECTED.TO.DEV.NULL> wrote in message
news:3ABA618B.DA3D844E@SPAM.REDIRECTED.TO.DEV.NULL…
Now I’m no expert on h4X0r1ng but just on a quick glance at the spin
code,
doesn’t the _cmdname() call return an arbitrary path with length that
should be determined by pathconf()? You’re reading into a buffer of
length
_POSIX_PATH_MAX (256) so could not that be overrun? Next thing you
know
someone’s smashing your stack and you’re in a world of hurt. This may
not
be exploitableCurrent handling of SIGWINCH is ugly in the first place. And yes, it is
insecure if spin is SUID root, although if you get nasty and launch spin
using over 255 characters path you’ll more likely get SIGSEGV than hackNote that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…
Hi Rick
Could you explain this in a little more detail. You you saying that someone
could write their own program as non-root to gain root access or cause
someone else’s program that is SUID root to gain root access?
In either case, what is the cure for this?
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
Bill Caroselli wrote:
“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
[…]
Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…Hi Rick
Could you explain this in a little more detail. You you saying that someone
could write their own program as non-root to gain root access or cause
someone else’s program that is SUID root to gain root access?
Hi Bill,
The latter case is what I was referring to. With “non-privileged user” I
mean a user logged in as non-root. His shell is running as non-root. But
he can attack a root privileged process (i.e. a SUID program started up,
or a program already running as root) which has a vulnerability and
eventually let that program fork() or exec() a shell, thus gaining root
privileges. Or perhaps let that attacked program modify the
password/shadow file in a convenient way (like change root’s password,
or change his own uid/gid to 0, or … use your imagination here
Common sense would suggest that a non-root process, whatever instruction
it executes, could never become a root process, unless the OS (process
manager) provides such a feature (or bug). However, I learned to keep an
open mind about these things and won’t venture to say that it is
absolutely impossible. The job of an OS is very complex thus increasing
the chances of unwanted backdoors.
In either case, what is the cure for this?
Now that’s a big question
I’m not an expert on security, but generally I see two common
approaches:
Be very dammed careful when writing programs which are to be run
SUID.
Where possible, let your process fork() a child process which
relinquishes its root privileges and becomes a non-root process before
servicing the request. (Or if it’s only a one-time request, then the
parent it self can perform these steps and then exit.)
Of course you know the common implementation of method 2 in a
client/server model, where the server running as root receives requests
from clients, checks their authenticity and executes them in a
controlled, well-defined manner.
regards,
rick
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
Those are very interesting issues, but you guys keep this discussion in
wrong newsgroup and under wrong subject. They have very little to do
specifically with QNX or SPIN.
As I said before, SPIN has no Internet connections and does no serve any
external requests. Thus, it can be attacked only by someone who already
has shell access. Now, if you’re paranoid about security you should know
better that shell access to outside users is a security threat to begin
with. In general, if I am a malicious user with shell access and ability
to run arbitrary programs (let alone compile-and-run my own programs)
then you’re in deep trouble long before I even start SPIN.
I really suggest you to continue in a separate thread.
Rick Lake wrote:
Bill Caroselli wrote:
“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
[…]
Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…Hi Rick
Could you explain this in a little more detail. You you saying that someone
could write their own program as non-root to gain root access or cause
someone else’s program that is SUID root to gain root access?
Hi Bill,The latter case is what I was referring to. With “non-privileged user” I
mean a user logged in as non-root. His shell is running as non-root. But
he can attack a root privileged process (i.e. a SUID program started up,
or a program already running as root) which has a vulnerability and
eventually let that program fork() or exec() a shell, thus gaining root
privileges. Or perhaps let that attacked program modify the
password/shadow file in a convenient way (like change root’s password,
or change his own uid/gid to 0, or … use your imagination here >Common sense would suggest that a non-root process, whatever instruction
it executes, could never become a root process, unless the OS (process
manager) provides such a feature (or bug). However, I learned to keep an
open mind about these things and won’t venture to say that it is
absolutely impossible. The job of an OS is very complex thus increasing
the chances of unwanted backdoors.
In either case, what is the cure for this?
Now that’s a big question >I’m not an expert on security, but generally I see two common
approaches:
Be very dammed careful when writing programs which are to be run
SUID.Where possible, let your process fork() a child process which
relinquishes its root privileges and becomes a non-root process before
servicing the request. (Or if it’s only a one-time request, then the
parent it self can perform these steps and then exit.)Of course you know the common implementation of method 2 in a
client/server model, where the server running as root receives requests
from clients, checks their authenticity and executes them in a
controlled, well-defined manner.regards,
rick
\Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
Yes I totally agree with you. Sorry about that. In fact I was thinking
about posting a follow-up to say that this thread should predominantly
be about thanking you for your contribution with this utility, but you
beat me to it.
Keep up the good work!
rick
Igor Kovalenko wrote:
Those are very interesting issues, but you guys keep this discussion in
wrong newsgroup and under wrong subject. They have very little to do
specifically with QNX or SPIN.As I said before, SPIN has no Internet connections and does no serve any
external requests. Thus, it can be attacked only by someone who already
has shell access. Now, if you’re paranoid about security you should know
better that shell access to outside users is a security threat to begin
with. In general, if I am a malicious user with shell access and ability
to run arbitrary programs (let alone compile-and-run my own programs)
then you’re in deep trouble long before I even start SPIN.I really suggest you to continue in a separate thread.
- Igor
Rick Lake wrote:
Bill Caroselli wrote:“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
[…]
Note that those script kiddies exploit SIGSEGV’s to find holes. I
haven’t seen your code, but if the buffer is on the stack, they would
overrun it with instruction code to return to a convenient place where
they put more instruction code to do all kinds of stuff. I’ve once seen
a demo on a seminar where a non-privileged user gained root privileges
that way. That was a wakeup call for me…Hi Rick
Could you explain this in a little more detail. You you saying that someone
could write their own program as non-root to gain root access or cause
someone else’s program that is SUID root to gain root access?
Hi Bill,The latter case is what I was referring to. With “non-privileged user” I
mean a user logged in as non-root. His shell is running as non-root. But
he can attack a root privileged process (i.e. a SUID program started up,
or a program already running as root) which has a vulnerability and
eventually let that program fork() or exec() a shell, thus gaining root
privileges. Or perhaps let that attacked program modify the
password/shadow file in a convenient way (like change root’s password,
or change his own uid/gid to 0, or … use your imagination here >Common sense would suggest that a non-root process, whatever instruction
it executes, could never become a root process, unless the OS (process
manager) provides such a feature (or bug). However, I learned to keep an
open mind about these things and won’t venture to say that it is
absolutely impossible. The job of an OS is very complex thus increasing
the chances of unwanted backdoors.
In either case, what is the cure for this?
Now that’s a big question >I’m not an expert on security, but generally I see two common
approaches:
Be very dammed careful when writing programs which are to be run
SUID.Where possible, let your process fork() a child process which
relinquishes its root privileges and becomes a non-root process before
servicing the request. (Or if it’s only a one-time request, then the
parent it self can perform these steps and then exit.)Of course you know the common implementation of method 2 in a
client/server model, where the server running as root receives requests
from clients, checks their authenticity and executes them in a
controlled, well-defined manner.regards,
rick
\Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“Rick Lake” <rwlake@SPAM.REDIRECTED.TO.DEV.NULL> wrote in message
news:3ABD0331.8FD91E66@SPAM.REDIRECTED.TO.DEV.NULL…
Yes I totally agree with you. Sorry about that. In fact I was thinking
about posting a follow-up to say that this thread should predominantly
be about thanking you for your contribution with this utility, but you
beat me to it.
In fact the way to thank me is to send postcard. So far one (1) user managed
to do that so I’m starting to feel like QNX community must be either very
small or very ungrateful
As of this thread, it should be used predominantly to discuss problems or
offer suggestions, patches, etc. As long as they are relevant…
“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:99m6n3$it2$1@inn.qnx.com…
“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 3ABD0331.8FD91E66@SPAM.REDIRECTED.TO.DEV.NULL> …
Yes I totally agree with you. Sorry about that. In fact I was thinking
about posting a follow-up to say that this thread should predominantly
be about thanking you for your contribution with this utility, but you
beat me to it.
In fact the way to thank me is to send postcard. So far one (1) user
managed
to do that so I’m starting to feel like QNX community must be either very
small or very ungrateful >
Now various people told me they either have no idea what e-cards are or
somehow confused about them.
I really thought it is simple. See http://www.e-cards.com or
http://www.amazon.com (click on free e-cards) or http://greetings.yahoo.com
or whatever else. The idea is the same everywhere. You use your browser to
compose an ‘e-postcard’ by choosing a picture and adding some text. Then it
will be formatted as HTML and sent by e-mail.
Why do I want e-cards instead of plain e-mail? I like nice pictures. And by
choosing pictures people express themselves so I know them better than if
they just wrote something. And I’m curious