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
I propose that the owners of various utilities answer at least these
questions about them:
- Does it REALLY need to be suid root?
a) Is there a way that it can give up root privileges earlier in it’s
b) Could it possibly be done with sgid and some clever setup of groups?
- Does it accept arbitrary files as input?
- Does it execute anything based on $PATH?
- Does it depend in any way on environment that can be modified by an
The list of suid binaries on my current 6.2 system are:
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.
<email@example.com> wrote in message news:firstname.lastname@example.org…
Two local root exploits have been discovered for qnx 6, one of which is
to work in the released version of 6.2. The detail of the exploits (and
possible workarounds) are available from the qnxZone website.
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