Apparently some of you are under the impression that the security community is some sort of professional organization, like the IEEE, that you have to obtain membership from to participate.
You are wrong. What we know about security in 1999 is 90% the result of independant research work done by people trying to find new ways to break into computer systems.
The security community is aware of stack overflow vulnerabilities in large part due to a successful attack on the Internet that happened in the 80s. The relevance of the attack on modern Unix systems was underscored by the 8lgm (with the Sendmail 8.6.12 advisory), a group that did nothing but post exploit code for new security problems they discovered. And immense code audits that Linux and 4.4BSD went through to overflows were the direct result of Mudge and Aleph One posting detailed "how-to-write-an-exploit" cookbooks for hackers.
Nobody of any repute in the security community criticizes any of these people for what they've done. To do so would be silly; we know that our software would be less secure without these people, as well as we know that crackers had access to the information long before we did.
The entire security community is BASED on the concept of PEER REVIEW, where anonymous strangers (preferably scruffy college kids, for theatric effect) scour published code and design documents and find flaws. We wouldn't have Blowfish and IDEA if it weren't for Biham and Shamir ripping up DES.
cDc is following along in the same tradition, and it's a tradition that we need to ensure is maintained. Nobody is doing the security community any favors by attempting to villify Sir Dystik. It is incredibly important that we not set a precedent for shooting the messenger.
/proc isn't the only source of information about what pids are on the system. That data is leaked through many, many interfaces to the kernel. It is tedious and tricky to plug all of those leaks, which is exactly what you need to do to write a process-hiding trojan under Linux or BSD --- since anyone can read the kernel source to find a new avenue to locate hidden processes.
Man kill(2). Look at what kill(0,pid) does.
Better:
Man fork(2). Look at what the parent receives as a return value.
The problem with systems like NT (and, to a lesser extent, Solaris) is that there isn't enough published information to give white-hats the advantage over black-hats in the hide- versus-seek battle of trojan development.
WinNT is just as secure, if not more secure, than most Unix systems. I see hundreds of new exploits for Unix systems every week, but much fewer available for NT.
This is silly logic. Of course you see more "Unix exploits" than NT exploits. Unix is open source, which makes it easier to find exploits. The only people that have comparable resources and ability in the NT community are not going to release their discoveries to the public.
WinNT is just as secure, if not more secure, than most Unix systems. I see hundreds of new exploits for Unix systems every week, but much fewer available for NT.
This is silly logic. Of course you see more "Unix exploits" than NT exploits.
What are you talking about? This is certainly not the only way to "prevent things like this".
First, all trojans take advantage of capabilities offered by the systems they infect. Kernel trojans take advantage of device drivers and context switching code. In this respect, all operating system functionality is subject to misuse by malicious code (such as BO2K). Obviously, this is not the problem that needs to be "fixed".
Next, the issue being discussed with respect to trojans that affect OS kernels is detectability. It simply is HARDER to detect a well-written NT trojan. The security community does not have the detailed information about the NT OS internals needed to develop good detection schemes for kernel trojans.
This stands in stark contrast to Linux trojans, which must in some manner be based on and affect the operation of the Linux kernel. The difference here is that the effect of a Linux kernel trojan is made measurable by the amount of information publically available on the Linux kernel.
Unlike NT.
Finally, the point you're making ("the only fix is to remove the functionality") is completely bogus. The problem is that NT is configured and used in a way that makes the distribution of BO and it's siblings trivial. That is not a hard problem to solve. "Don't run unverified code inside of mail attachments". "Don't run programs you get from suspicious sources." "MD5 binaries you distribute to the public."
This problem already does affect Linux. There are published kernel trojans in Phrack magazine.
The issue is that in normal Linux installations, the only way to actually use a BO-like tool is to gain root access to the server first. When that occurs, the means by which root access was gained is almost IMMEDIATELY published and resolved.
You would "fix this problem" by ensuring that users who run applications like mail readers that have the ability to execute content provided by untrusted sources would NOT at the same time have the privileges required to install something like BO2K.
It's not like BO2K can just point at an arbitrary NT installation and magically infect it.
A.) Please stop using analogies to communicate. Read the discussion so far. Do you notice that people are wasting more breath discussing the flaws in the analogies than they are the issue itself? cDc didn't infect meat or steal cars. They wrote code. I think we're intelligent enough to discuss that.
B.) cDc didn't create ANY security problems. The attitude that says they did is called "security through obscurity", and it doesn't work. The computer underground is consistantly and blatantly underestimated by people, most of whom have no connection to the security research community, who think that system crackers didn't have tools prior to their public release.
The functional equivalent of Back Orifice was already in the hands of people you definitely did NOT want to have these tools long before Sir Dystik released the first Back Orifice trojan.
Why aren't you auditing your Windows NT servers anyways? This program isn't breaking into your servers; "viruses" and security holes are. cDc has "caused" none of these problems.
Windows NT "moralists" complaining about this problem have their heads in the sand. The problem is that circumstances exist to allow programs like BO2K to be installed in the first place.
You lack a very basic understanding of computer security and threat analysis if you think that the computer underground (ie, the community of system crackers) didn't already have tools of comparable power already. Posting BO2K simply prevents IT managers and Microsoft marketeers from denying this simple truth.
You should be thanking cDc for A.) raising awareness of the problem and B.) ensuring that 99% of all successful NT attacks will have the uniform signature of a BO2K installation to accompany them...
... as opposed to either the obvious signature of a wiped hard disk, or the much-harder-to-track signature of a custom-coded trojan.
Modifying system calls does not make a trojan undetectable, even "pretty much". Because of the fact that kernel source is readily available to both white hats AND black hats, crackers who want to develop "stealth trojans" have a considerably harder time under Linux than under NT (where the kernel source is available only to black hats).
This is a fundamental security advantage held only by open-source operating systems.
>The code is significantly smaller and easier >to understand
Uh. I totally disagree. Having done kernel work on both platforms, I find Linux to be significantly easier to work with and understand. Compare the IP stacks or the drivers.
Write them and complain. Elias and Jennifer have been maintaining Bugtraq and the archives for years, for no compensation, out of the kindness of their hearts. A nice way to return the favor would be to give them constructive feedback.
The Geek-Girl archives were started first. Geek-Girl was hosting Bugtraq (even before it was Geek-Girl, back when it was a machine at NWU) since the before Elias (Aleph) took over the list.
Note that both "Geek-Girl" (Jennifer Myers) and "Aleph One" (Elias Levy) have prominent roles at SecurityFocus.
Anything good I say about SecurityFocus will be biased by the fact that it is run by friends of mine.
Slashdot Mirror
Apparently some of you are under the impression
that the security community is some sort of
professional organization, like the IEEE, that
you have to obtain membership from to participate.
You are wrong. What we know about security in
1999 is 90% the result of independant research
work done by people trying to find new ways to
break into computer systems.
The security community is aware of stack overflow
vulnerabilities in large part due to a successful
attack on the Internet that happened in the 80s.
The relevance of the attack on modern Unix systems
was underscored by the 8lgm (with the Sendmail
8.6.12 advisory), a group that did nothing but
post exploit code for new security problems they
discovered. And immense code audits that Linux
and 4.4BSD went through to overflows were the
direct result of Mudge and Aleph One posting
detailed "how-to-write-an-exploit" cookbooks for
hackers.
Nobody of any repute in the security community
criticizes any of these people for what they've
done. To do so would be silly; we know that our
software would be less secure without these
people, as well as we know that crackers had
access to the information long before we did.
The entire security community is BASED on the
concept of PEER REVIEW, where anonymous strangers
(preferably scruffy college kids, for theatric
effect) scour published code and design documents
and find flaws. We wouldn't have Blowfish and
IDEA if it weren't for Biham and Shamir ripping
up DES.
cDc is following along in the same tradition,
and it's a tradition that we need to ensure is
maintained. Nobody is doing the security community
any favors by attempting to villify Sir Dystik.
It is incredibly important that we not set a
precedent for shooting the messenger.
You don't get it.
/proc isn't the only source of information
about what pids are on the system. That data
is leaked through many, many interfaces to the
kernel. It is tedious and tricky to plug all
of those leaks, which is exactly what you need
to do to write a process-hiding trojan under
Linux or BSD --- since anyone can read the kernel
source to find a new avenue to locate hidden
processes.
Man kill(2). Look at what kill(0,pid) does.
Better:
Man fork(2). Look at what the parent receives
as a return value.
The problem with systems like NT (and, to a
lesser extent, Solaris) is that there isn't
enough published information to give white-hats
the advantage over black-hats in the hide-
versus-seek battle of trojan development.
WinNT is just as secure, if not more secure, than most Unix systems. I see hundreds of new exploits for Unix systems every week, but much fewer available for NT.
This is silly logic. Of course you see
more "Unix exploits" than NT exploits.
Unix is open source, which makes it easier
to find exploits. The only people that
have comparable resources and ability in
the NT community are not going to release
their discoveries to the public.
WinNT is just as secure, if not more secure, than most Unix systems. I see hundreds of new exploits for Unix systems every week, but much fewer available for NT.
This is silly logic. Of course you see
more "Unix exploits" than NT exploits.
It doesn't hide processes. man kill(1).
I'm sure comparable problems exist in the
manner it hides files.
What are you talking about? This is certainly
not the only way to "prevent things like this".
First, all trojans take advantage of capabilities
offered by the systems they infect. Kernel trojans
take advantage of device drivers and context
switching code. In this respect, all operating
system functionality is subject to misuse by
malicious code (such as BO2K). Obviously, this
is not the problem that needs to be "fixed".
Next, the issue being discussed with respect to
trojans that affect OS kernels is detectability.
It simply is HARDER to detect a well-written NT
trojan. The security community does not have
the detailed information about the NT OS internals
needed to develop good detection schemes for
kernel trojans.
This stands in stark contrast to Linux trojans,
which must in some manner be based on and affect
the operation of the Linux kernel. The difference
here is that the effect of a Linux kernel trojan
is made measurable by the amount of information
publically available on the Linux kernel.
Unlike NT.
Finally, the point you're making ("the only fix
is to remove the functionality") is completely
bogus. The problem is that NT is configured and
used in a way that makes the distribution of BO
and it's siblings trivial. That is not a hard
problem to solve. "Don't run unverified code
inside of mail attachments". "Don't run programs
you get from suspicious sources." "MD5 binaries
you distribute to the public."
This isn't rocket science.
This problem already does affect Linux. There
are published kernel trojans in Phrack magazine.
The issue is that in normal Linux installations,
the only way to actually use a BO-like tool is
to gain root access to the server first. When that
occurs, the means by which root access was gained
is almost IMMEDIATELY published and resolved.
You would "fix this problem" by ensuring that
users who run applications like mail readers that
have the ability to execute content provided by
untrusted sources would NOT at the same time have
the privileges required to install something like
BO2K.
It's not like BO2K can just point at an arbitrary
NT installation and magically infect it.
A.) Please stop using analogies to communicate.
Read the discussion so far. Do you notice that
people are wasting more breath discussing the
flaws in the analogies than they are the issue
itself? cDc didn't infect meat or steal cars.
They wrote code. I think we're intelligent enough
to discuss that.
B.) cDc didn't create ANY security problems. The
attitude that says they did is called "security
through obscurity", and it doesn't work. The
computer underground is consistantly and blatantly
underestimated by people, most of whom have no
connection to the security research community,
who think that system crackers didn't have tools
prior to their public release.
The functional equivalent of Back Orifice was
already in the hands of people you definitely did
NOT want to have these tools long before Sir Dystik released the first Back Orifice trojan.
Pull your head out of the sand.
Of course they're in it for the attention.
Just like everyone else working in computer
security research.
Fortunately, the goals of the security community
are compatible with those of Sir Dystik.
Amen. cDc will have a hard time claiming BO2K
is a "powerful administration tool" if it is
comparably secure to the original BO.
Why aren't you auditing your Windows NT
servers anyways? This program isn't breaking
into your servers; "viruses" and security
holes are. cDc has "caused" none of these
problems.
Windows NT "moralists" complaining about this
problem have their heads in the sand. The
problem is that circumstances exist to allow
programs like BO2K to be installed in the first
place.
You lack a very basic understanding of computer
security and threat analysis if you think that
the computer underground (ie, the community of
system crackers) didn't already have tools of
comparable power already. Posting BO2K simply
prevents IT managers and Microsoft marketeers
from denying this simple truth.
You should be thanking cDc for A.) raising
awareness of the problem and B.) ensuring that
99% of all successful NT attacks will have the
uniform signature of a BO2K installation to
accompany them...
... as opposed to either the obvious signature
of a wiped hard disk, or the much-harder-to-track
signature of a custom-coded trojan.
Modifying system calls does not make a trojan
undetectable, even "pretty much". Because of the
fact that kernel source is readily available to
both white hats AND black hats, crackers who want
to develop "stealth trojans" have a considerably
harder time under Linux than under NT (where the
kernel source is available only to black hats).
This is a fundamental security advantage held
only by open-source operating systems.
>The code is significantly smaller and easier
>to understand
Uh. I totally disagree. Having done kernel work
on both platforms, I find Linux to be significantly easier to work with and understand. Compare the IP stacks or the drivers.
> It actually bother's the hell out of me that
> *all* ISPs are this spineless. Their legal
> agreements all *suck*.
What do you expect? If they didn't do this,
they'd inevitably get sued. It's not like this
is *needless* C.Y.A.
Blame the laws that prevent ISPs from being
treated purely as common carriers, not the ISP
industry's reaction to them.
Write them and complain. Elias and Jennifer
have been maintaining Bugtraq and the archives
for years, for no compensation, out of the
kindness of their hearts. A nice way to return
the favor would be to give them constructive
feedback.
The web guy at SecurityFocus is Dave Ahmed,
.
The Geek-Girl archives were started first.
Geek-Girl was hosting Bugtraq (even before
it was Geek-Girl, back when it was a machine
at NWU) since the before Elias (Aleph)
took over the list.
Note that both "Geek-Girl" (Jennifer Myers)
and "Aleph One" (Elias Levy) have prominent
roles at SecurityFocus.
Anything good I say about SecurityFocus will
be biased by the fact that it is run by friends
of mine.
If you want ALSA support and it isn't happening
fast enough, two suggestions:
- Write it yourself, submit it, and
post it on a web page somewhere.
- Pay someone (in cash, beer, gratitude)
to do it.
It's not only GPL'd code, it's good code (I
spent the night working with it). It can't be "stolen" or "Microsofted".
If you want ALSA support and don't see it
happening fast enough, two suggestions: