Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Jeff Thompson (thompsonARGUS-SYSTEMS.COM)
Date: Fri Mar 30 2001 - 22:03:45 CST
This morning a message was posted on bugtraq by Blazde/Roland about the
recent Argus hacking contest at CeBit in Germany and an exploit he
discovered on one of the systems being protected by one of the products
in the Argus PitBull product line. I wanted to give an unofficial
response to a few of the issues mentioned by Roland. I'm an employee of
Argus (very technical, not marketing or sales, even though my title may
not give you that impression) and am very familiar with the PitBull LX
product that Roland was referring to.
As Roland mentioned, he located a misconfiguration in our integration of
the PitBull LX technology into the 'sysctl' system call. This system call
makes a permission to see if a user can access its functionality. 'sysctl'
allows a 'root' user to modify the modprobe kernel parameters. Therefore, a
user must first become root in order to exploit this. In order to fix this
problem, a simple security flag access check needs to be added to this system
call. Once in place, this ability will no longer be available to attackers
who are being restricted by the PitBull LX technology.
Unfortunately for Roland, he never actually managed break the system in the
way required for the contest. The systems in the contest stayed up almost
half a day past the end of the contest, and much of Roland's work was done
during that time. Roland did a great job of analyzing the system and
showed a lot of persistence in tracking down potential exploits. I can
understand his frustration for coming so close but missing the deadline.
Apparently Roland's frustration was showing when he commented about the
web sites "disappearing" and Argus not wanting to release an official
press release. After each hacking contest, Argus disconnects the systems
associated with hacking contest -- the CeBit contest was no different.
The systems weren't even shut down immediately, they were left running
for many hours. There was nothing diabolical about the fact that the
systems were eventually shut down. This was definitely not an attempt
to squeek by without noticing that something had happened.
In fact, it was when the administrators of this contest logged in via
sshd in order to shut down the systems that they tripped the "trojan"
that Roland had put into place. Unfortunately, the code that was run
by Roland did not modify the system in the proscribed way by the rules,
and in fact was run after the contest had ended.
There also seems to be a misunderstanding here about Argus not wanting
the fact that this occurred to be made public. While we of course wish
that we would have put the check into the 'sysctl' system call for
security flags so that Roland would not have found a way to use it to
his advantage, the fact is that Roland did in fact find a way to do it.
The fact is that we received specific information on the exploit
Wednesday in the late afternoon (Central Standard Time). The post to
BugTraq was made available Friday morning. I believe that it is extremely
unfortunate that we were not given much more than 24 hours to produce
a patch for the problem, run it through our quality assurance group,
and notify our customers and members of this forum of the problem. Let
alone to release a press release that discusses the events.
I am also sorry that Roland feels that we were unresponsive in regards
to this problem. This is particularly troubling, as we are a company
that prides itself on our responsiveness and support of our products.
I believe this is very significant in an industry where the standard
is to either blame any problems a companies software has on another
vendor (it must be the OS's fault, or 'oh! your using X's product,
well you should call them'), or to simply not return queries in
anything close to a timely manner.
With that said, a source code patch for the kernel is being attached to
this message, and will be made available on the main Argus corporate web
site as well as the Argus Revolution server. We are also notifying our
customers of the problem.
For Argus, PitBull LX is an extremely new product (our other mainstay
product PitBull Foundation has been around for years). PitBull LX is
the next generation of Trusted Operating System technology, and was
designed from the ground up to provide the most important pieces of
functionality that are found in traditional Trusted Operating Systems,
but in a way that more closely matches the standard Unix environment
and the security models that are being used in the real world to protect
these systems. We are understandably very proud of the product, and had
the confidence in the technology to make it a part of these contests in
order to expose the technology to the world, and to put it in the ring
(so to speak). It is gratifying to know that after spending a lot of
time involving himself with the technology, and finding a problem in our
security flag checks, that Roland still thinks highly of the technology.
While we are hard at work making sure that our PitBull LX technology and
product is properly integrated into the Linux environment, it is my hope
that if additional problems are found in the product as it grows, we will
be given the opportunity to demonstrate our responsiveness and dedication
to providing a real security solution, rather than just snake oil.
- TEXT/PLAIN attachment: ASGLX20010301.README
- TEXT/PLAIN attachment: ASGLX20010301.patch