security postings

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Two local root exploits have been discovered for qnx 6, one of which is known
to work in the released version of 6.2. The detail of the exploits (and some
possible workarounds) are available from the qnxZone website.

http://www.qnxzone.com/readmore.php?news_id=156

AND

http://www.qnxzone.com/readmore.php?news_id=155

I am disappointed that there has been no official notice from QSSL about
these issues which have been known to them for some time. I would like to
see official CERT advisiories issued by QSSL. I feel it is extremely
important for QSSL to show that they are actively working on correcting such
issues.

Cheers,
Camz.

2

I would like to assure you and the community that we DO care about security
here. In fact, not too long ago, I filed a PR with the following text:

All suid binaries shipped with RTP should be audited for basic security
sanity.

I propose that the owners of various utilities answer at least these
questions about them:

  1. Does it REALLY need to be suid root?
    a) Is there a way that it can give up root privileges earlier in it’s
    execution?
    b) Could it possibly be done with sgid and some clever setup of groups?
  2. Does it accept arbitrary files as input?
  3. Does it execute anything based on $PATH?
  4. Does it depend in any way on environment that can be modified by an
    attacker?

The list of suid binaries on my current 6.2 system are:
/bin/su
/bin/netmanager
/bin/login
/usr/sbin/pci
/usr/sbin/pppoed
/usr/sbin/pppd
/usr/photon/bin/qnxinstall
/usr/photon/bin/pkg-installer
/usr/photon/bin/inputtrap
/usr/photon/bin/fontsleuth
/usr/photon/bin/do_font
/usr/photon/bin/Photon
/usr/photon/bin/phfont
/usr/photon/bin/phshutdown
/usr/photon/bin/phlocale
/usr/photon/bin/phgrafx-startup
/usr/photon/bin/phgrafx
/usr/photon/bin/input-cfg
/usr/photon/bin/phrelaycfg
/usr/bin/cl-installer
/usr/bin/crttrap
/usr/bin/packager
/usr/bin/passwd
/usr/bin/traceroute
/usr/bin/netstat
/usr/bin/rsh
/usr/bin/rlogin
/usr/bin/rcp
/usr/bin/newgrp
/usr/bin/lprrm
/usr/bin/lprq
/usr/bin/lprc
/usr/bin/lpr
/usr/bin/lpd
/usr/bin/ping

This is one thing that can be done to eliminate local root exploits. The
other proposal in the works is for a continuous auditing process for all
remote services. This would involve making sure that all public ported
software is up to date with current security patches as well as publishing
safety tables for various services: ie. QNET should be used in closed
networks, telnetd should be used in trusted networks, etc. Ensuring that
all untrusted input is properly validated and string copying is properly
bounded would, of course, be part of this.

As various people have said, our primary goal is embedded systems where
exploits are not usually an issue. Being used as a server in untrusted
environments is relatively new to this company so the process of becoming
secure requires a great deal of work and dedication. Making a Unix type
system secure is an extremely non-trivial exercise: consider the process
OpenBSD has been undergoing for years. We want to ensure basic security is
in place for those who do choose to use us as a server… and, as you said,
openness and accountability is also a part of that and our internal
processes in this regard will also need auditing.

cheers,

Kris

<camz@passageway.com> wrote in message news:ahmise$in2$1@inn.qnx.com…

Two local root exploits have been discovered for qnx 6, one of which is
known
to work in the released version of 6.2. The detail of the exploits (and
some
possible workarounds) are available from the qnxZone website.

http://www.qnxzone.com/readmore.php?news_id=156

AND

http://www.qnxzone.com/readmore.php?news_id=155

I am disappointed that there has been no official notice from QSSL about
these issues which have been known to them for some time. I would like to
see official CERT advisiories issued by QSSL. I feel it is extremely
important for QSSL to show that they are actively working on correcting
such
issues.

Cheers,
Camz.

3

The list of suid binaries on my current 6.2 system are:

/usr/bin/cl-installer
This one definetely should not be suexec, cause it onloy could be ran by

root.

Dmitry Alexeyev

4

Kris Warkentin <kewarken@qnx.com> wrote:

I would like to assure you and the community that we DO care about security
here. In fact, not too long ago, I filed a PR with the following text:

Kris, that’s great. I was hoping to see such a response from QSS.
Can I copy your response to the comment thread on qnxzone?

other proposal in the works is for a continuous auditing process for all
remote services. This would involve making sure that all public ported
software is up to date with current security patches as well as publishing
safety tables for various services: ie. QNET should be used in closed
networks, telnetd should be used in trusted networks, etc. Ensuring that
all untrusted input is properly validated and string copying is properly
bounded would, of course, be part of this.

This would be great, while embedded devices are usually not vulnerable to
local root exploits, they typically are vulnerable to buffer overflows and
such. Depending on the type of embedded device a remote compromise could
have some nasty consequences.

I would still like to see CERT advisories from QSS. I have updated the news
postings on qnxZone to include workarounds for the exploits that are shown
in the stories. It would be much better if such things came directly from QSS.

Cheers,
Camz.

5

<camz@passageway.com> wrote in message news:ahmt4q$qhu$1@inn.qnx.com…

Kris Warkentin <> kewarken@qnx.com> > wrote:
I would like to assure you and the community that we DO care about
security
here. In fact, not too long ago, I filed a PR with the following text:

Kris, that’s great. I was hoping to see such a response from QSS.
Can I copy your response to the comment thread on qnxzone?

Certainly.

other proposal in the works is for a continuous auditing process for all
remote services. This would involve making sure that all public ported
software is up to date with current security patches as well as
publishing
safety tables for various services: ie. QNET should be used in closed
networks, telnetd should be used in trusted networks, etc. Ensuring
that
all untrusted input is properly validated and string copying is properly
bounded would, of course, be part of this.

This would be great, while embedded devices are usually not vulnerable to
local root exploits, they typically are vulnerable to buffer overflows and
such. Depending on the type of embedded device a remote compromise could
have some nasty consequences.

I would still like to see CERT advisories from QSS. I have updated the
news
postings on qnxZone to include workarounds for the exploits that are shown
in the stories. It would be much better if such things came directly from
QSS.

I can’t comment on this but I will certainly recommend it to those who can.

Cheers,
Camz.