HORRORS!!!

http://archives.neohapsis.com/archives/bugtraq/2002-05/0292.html

I’ve just checked my QNX v4.25G as an unprivileged user running
“crttrap -c /etc/shadow”
and it dumped the hashed passwords!

According to the link above it is known since 2002. Will QSSL address this?
What is the hot-fix to use right now?

Tony.

Tony <mts.spb.suxx@mail.ru> wrote:

http://archives.neohapsis.com/archives/bugtraq/2002-05/0292.html

I’ve just checked my QNX v4.25G as an unprivileged user running
“crttrap -c /etc/shadow”
and it dumped the hashed passwords!

According to the link above it is known since 2002. Will QSSL address this?
What is the hot-fix to use right now?

hotfix?
how about
as root, chmod u-s crttrap
better yet, review all the setuid programs on your box.

by the way, mario is correct that QSS doesn’t really care much about security
probably because

  1. they think everyone on the box should be root anyways.
  2. the box is in an isolated environment anyways.

Tony.

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

  1. they think everyone on the box should be root anyways.
  2. the box is in an isolated environment anyways.

http://xforce.iss.net/xforce/xfdb/9341

Thes above link scares me to death…

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?!

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opsfyhauico93ri4@mobile…

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

  1. they think everyone on the box should be root anyways.
  2. the box is in an isolated environment anyways.

http://xforce.iss.net/xforce/xfdb/9341

Thes above link scares me to death…

Well unless an attacker as means to run those there isn’t much he can do. I
would feel secure about using Tcpip only, but as soon as a port is open to a
know program, telnet, ftp etc then all hell breaks loose.

If you need hardcore security get an OS that suits the purpose.

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?!

Tony.

On Sat, 16 Oct 2004 19:27:43 -0400, Mario Charest <nowheretobefound@8thdimension.com> wrote:

Well unless an attacker has means to run those there isn’t much he can do. I
would feel secure about using Tcpip only, but as soon as a port is open to a
know program, telnet, ftp etc then all hell breaks loose.
Only SSH2 is planned to run there.

If you need hardcore security get an OS that suits the purpose.

I’d like to know that Tcpip is not so easily nuked as it was with windoze v3.11 that ANY script kiddy is able to cause a headache to me…

I’m going to dig out all those malwarez to try them against TCP/IP v5.0 myself.

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opsf0f44fyo93ri4@mobile…

On Sat, 16 Oct 2004 19:27:43 -0400, Mario Charest
nowheretobefound@8thdimension.com> > wrote:
Well unless an attacker has means to run those there isn’t much he can
do. I
would feel secure about using Tcpip only, but as soon as a port is open
to a
know program, telnet, ftp etc then all hell breaks loose.
Only SSH2 is planned to run there.

If you need hardcore security get an OS that suits the purpose.

I’d like to know that Tcpip is not so easily nuked as it was with windoze
v3.11 that ANY script kiddy is able to cause a headache to me…

I’m going to dig out all those malwarez to try them against TCP/IP v5.0
myself.

I do not beleive any available current available malwarez is going to pose a
security thread. Getting a program to SIGSEGV is one thing but getting it
to jump in the malcode ™ is another thing. The hacker would have to
target QNX4 specificaly, and they would have to know about which machine is
running QNX4 :wink:

Tony.

Mario Charest <nowheretobefound@8thdimension.com> wrote:

I do not beleive any available current available malwarez is going to pose a
security thread. Getting a program to SIGSEGV is one thing but getting it
to jump in the malcode ™ is another thing. The hacker would have to
target QNX4 specificaly, and they would have to know about which machine is
running QNX4 > :wink:

Also known as “Security Through Obscurity”.

On 18 Oct 2004 00:41:48 GMT, Frank Liu <fliu@usdjmp1.eng.vodafone-us.com> wrote:

Mario Charest <> nowheretobefound@8thdimension.com> > wrote:
I do not believe any available current malwarez is going to pose a security threat.
Getting a program to SIGSEGV is one thing but getting it to jump in the malcode ™ is another thing.

SIGSEGV is enough to cause a headache for any sysadmin!
BTW, how can I restart a box with SIGSEGV’ed stack?
Is it possible to detect automagically and react accordingly?

The hacker would have to target QNX4 specificaly, and they would have to know about which machine is running QNX4 > :wink:
Also known as “Security Through Obscurity”.
Yes, that is the wrong attitude to the problem.

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opsf2ejq0lo93ri4@mobile.wst.quantum.ru

On 18 Oct 2004 00:41:48 GMT, Frank Liu <> fliu@usdjmp1.eng.vodafone-us.com
wrote:

Mario Charest <> nowheretobefound@8thdimension.com> > wrote:
I do not believe any available current malwarez is going to pose a
security threat.
Getting a program to SIGSEGV is one thing but getting it to jump in the
malcode ™ is another thing.

SIGSEGV is enough to cause a headache for any sysadmin!
BTW, how can I restart a box with SIGSEGV’ed stack?
Is it possible to detect automagically and react accordingly?

You can write code that traps these error. Then it’s up to that program to
decide what to do: reboot the box, restart the application, etc.
This is what “dumper” does. You need to register for death message via
qnx_pflags.

The hacker would have to target QNX4 specificaly, and they would have to
know about which machine is running QNX4 > :wink:
Also known as “Security Through Obscurity”.
Yes, that is the wrong attitude to the problem.

Tony.

Tony <mts.spb.suxx@mail.ru> wrote:

On 18 Oct 2004 00:41:48 GMT, Frank Liu <> fliu@usdjmp1.eng.vodafone-us.com> > wrote:

Mario Charest <> nowheretobefound@8thdimension.com> > wrote:
I do not believe any available current malwarez is going to pose a security threat.
Getting a program to SIGSEGV is one thing but getting it to jump in the malcode ™ is another thing.

SIGSEGV is enough to cause a headache for any sysadmin!
BTW, how can I restart a box with SIGSEGV’ed stack?
Is it possible to detect automagically and react accordingly?

I have a little script for just that :slight_smile:
It’s called “monitor_ip”:

while true
do

Test for Socket and recover if required

slay -p Socket >/dev/null
if test “$?” = “0”
then
sh //1/etc/config/restart_ip
fi

Now, go to sleep for a few seconds so we don’t suck back all CPU

sleep 61
done

Crude, ugly, … and effective.

(Obviously, //1/etc/config/restart_ip does whatever you need to to restart the stack)

Cheers,
-RK

[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/

On 18 Oct 2004 12:52:55 GMT, Robert Krten <rk@parse.com> wrote:

I have a little script for just that > :slight_smile:
Thank you!

And what can you say about how often it had to work for you?
Judging on the manager name - you were using TCP/IP v4.xxX, can you compare it to the v5.0?

Tony.

Tony <mts.spb.suxx@mail.ru> wrote:

On 18 Oct 2004 12:52:55 GMT, Robert Krten <> rk@parse.com> > wrote:

I have a little script for just that > :slight_smile:
Thank you!
And what can you say about how often it had to work for you?
Judging on the manager name - you were using TCP/IP v4.xxX, can you compare it to the v5.0?

I run 4.x because “if it ain’t broken don’t fix it”. :slight_smile: So I can’t
give you any numbers on 5.0

Historically, it was failing a few times per month, just often enough
to be annoying. I haven’t seen a problem now in a long time. I use
it sometimes to “clean up” the stack when it gets bogged down by
just killing Socket – I know the script will fixup the system :slight_smile:

Cheers,
-RK


[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/

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

  1. they think everyone on the box should be root anyways.
  2. 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

On 18 Oct 2004 14:08:53 GMT, Robert Krten <rk@parse.com> wrote:

Historically, it was failing a few times per month, just often enough to be annoying.
Before going to TCP/IP v5.0 I was on an outdated TCP/IP v4.24 (patch level unknown).

It’s Sock[l]et was blowing as often as one~twice a week even without being exposed to Internet…
Since v5.0 (in the same environment) it does not happen (I’m “knocking on the wood”, i.e. on my own head :slight_smile: ) for quite a log time.

Now it’s time to handle the contemporary Internet realities…

I’ve found some collection of malwarez aimed mainly on windoze boxes, will try them on Tcpip soon.

Tony.

On 18 Oct 2004 15:39:40 GMT, David Gibbs <dagibbs@qnx.com> wrote:

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.
That particular link was just an example one.

The [un]complete list is here:
http://www.iss.net/search.php?config=corporate&pattern=QNX&x=0&y=0


The one that is setuid root, sample, is a development system tool for
doing application profiling, and should not be in any shipped system.
Yes, certainly we do not ship with everything installed. We do not depend on Photon, neither we ship any development tools.

But our scripts do depend on some /bin/* listed there, so it is possible to DoS the 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. Might be possible in
theory – in practice, probably not an issue.
My goal as of an admin is to secure the box by all means. We moved from telnet|ftp communications to SSH2, any user access to the shell is denyed. We were using some menus with just enough controls to do the job of a given user.

Now I go into creating a set of ssh keys that are limited to execute just one command each when authenticated. I try hard to deny tty allocation and any arbitrary commands…

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.
My lamentings were about the loss of confidence in the /usr/ucb/* code.

Tcpip in particular…

Is it as easily DoS’ed as was pre-1997 UNIX’s TCP/IP stack? I mean - did QSSL test it with such things as “teardrop”, “bonk”, “land” and friends?
http://www.insecure.org/sploits/land.ip.DOS.html
http://www.insecure.org/sploits/ping-o-death.html
http://www.insecure.org/sploits/95.NT.fragmentation.bonk.html
http://www.insecure.org/sploits/routed.tracefile.html
http://www.insecure.org/sploits/ttcp.spoofing.problem.html
http://www.insecure.org/sploits/redhat5.glibc.overflows.html
http://www.insecure.org/sploits/inetd.internal_udp_ports.DOS.attack.html
http://www.insecure.org/sploits/aix.generic.syslogd.problem.html
http://www.insecure.org/sploits/arp.games.html


Tony.

Tony <mts.spb.suxx@mail.ru> wrote:
T > On 18 Oct 2004 14:08:53 GMT, Robert Krten <rk@parse.com> wrote:

Historically, it was failing a few times per month, just often enough to be annoying.
T > Before going to TCP/IP v5.0 I was on an outdated TCP/IP v4.24 (patch level unknown).

T > It’s Sock[l]et was blowing as often as one~twice a week even without being exposed to Internet…
T > Since v5.0 (in the same environment) it does not happen (I’m “knocking on the wood”, i.e. on my own head :slight_smile: ) for quite a log time.

T > Now it’s time to handle the contemporary Internet realities…

T > I’ve found some collection of malwarez aimed mainly on windoze boxes, will try them on Tcpip soon.

5.0 worked much better for me too.
Plus it had features that I needed, like supernetting.

Now I’m on QNX6 so I’m not still using TCP/IP V5.0.

">

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.

I was told that’s how many system are compromised.

:frowning:

On 18 Oct 2004 15:39:40 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:
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.
That particular link was just an example one.
The [un]complete list is here:
http://www.iss.net/search.php?config=corporate&pattern=QNX&x=0&y=0
Seems, I found the buffer overflow in /bin/login too!

On both inputs (login name and password) it withstands no more than 255
characters. After that - it freeses.
May be, feeding it with the specially crafted input one may really gain
root privileges (assuming it was given “root” as the logname first)…
Now I can only DoS the box blowing as many /bin/login’s as Proc32 will
allow to run, after that limit one has to reboot the box.
:frowning:
(QNX v4.25G + Security patch)
I will check /bin/su and /bin/passwd too now.

Is it as easily DoS’ed as was pre-1997 UNIX’s TCP/IP stack? I mean - did
QSSL test it with such things as “teardrop”, “bonk”, “land” and friends?
http://www.insecure.org/sploits/land.ip.DOS.html
http://www.insecure.org/sploits/ping-o-death.html
http://www.insecure.org/sploits/95.NT.fragmentation.bonk.html
http://www.insecure.org/sploits/routed.tracefile.html
http://www.insecure.org/sploits/ttcp.spoofing.problem.html
http://www.insecure.org/sploits/redhat5.glibc.overflows.html
http://www.insecure.org/sploits/inetd.internal_udp_ports.DOS.attack.html
http://www.insecure.org/sploits/aix.generic.syslogd.problem.html
http://www.insecure.org/sploits/arp.games.html
I did try compiling some of the above, the /usr/ucb/Tcpip v5.0 withstood

my efforts…

Tony.