Are you people stupid? Am I missing sarcasm here? What are you thinking when you advocate Linux compile-time options for congestion- control subversion? That this is a "nifty feature" for Linux kernels to have?
Congestion control was developed in response to a congestion *crisis* in the late 1980s. Proper congestion control is a requirement for the Internet to function. The LACK of congestion control is common streaming and multicast protocols is a commonly cited major hurdle for the deployment of multicast applications on the Internet.
It's been a nightmare scenario for awhile now that Microsoft (they of the "transient failure" RST packet) would unscrupulously try to gain a competitive advantage by manipulating congestion control. By "breaking the rules" they could make a faster stack. Another scary thought is that silly "Internet Accelerator" products could actually sell REAL accelerators, that provide horsepower boosts at the expense of the entire network.
What you DON'T want to see happen is for Linux to gain "turbocharging" via congestion-ignorance. What that does is set up an arms race between Linux and every other stack vendor, and particularly Microsoft. That arms race could easily lead to congestion collapse and yet another Internet scaleability crisis.
What Stefan Savage is describing are VULNERABILITIES in common TCP/IP stacks. They need to be fixed, and programs that take advantage of them need to be considered in the same light as programs that get rid of pesky security measures on remote computers --- as exploits.
Just chiming in here, because I think it's odd that people here are paying more attention to the clever backtracking hack Savage came up with and less attention to the important, new security vulnerabilities he has documented.
Not everything Bruce Schneier says is right. The article you're citing is particularly wrong, and I wrote a formal response to it which you can find at SecurityFocus or my home page. Schneier, and possibly Mozilla as well, is missing the point of full disclosure.
We can debate the morality of nondisclosure ad nauseum. I'm more interested in engineering than morality --- and the fact of the matter is that policies that discourage full and open disclosure DO NOT WORK. They hinder the discovery of important security flaws and create an environment in which black hats have a significant advantage over white hats. Remember, the black hats don't give a damn about Mozilla's disclosure policies, and history tells us that they tend to find the problems first.
Nondisclosure has (dubious) practical benefits for tightly-guarded closed projects. Mozilla obviously doesn't qualify, and the idea that security flaws in Mozilla's open codebase can be meaningfully hidden is ludicrous.
As this is a Slashdot story, I don't trust the veracity of the claims that Mozilla is going to try to hide security information. However, if, contrary to the established best practices in the security community, they decide to go ahead with some sort of Mozilla "inner circle", they are going to give a nice black eye to Open Source's security argument.
Mr. Nelson, you've made it clear that you don't care whether Linux keeps its "buzz" or develops better application support. While I think this is an interesting 180 from your previous argument that "BSD is wrong because all development effort should be concentrated on Linux", I'm happy to accept your lack of concern over Linux's lifespan in the mainstream. However, I don't believe you have the majority opinion.
As a Linux software developer and a longtime free software user, I totally disagree with what you're saying and agree wholeheartedly with what the Globe article says. Mainstream acceptance of Linux and application support for the platform is more important than you seem to know, and I'd like to tell you why.
First and foremost, we need to move away from the notion that "applications" equal games and word processors. As a developer, it annoys (and costs) me that I have to maintain a Solaris or Win32 dev box in order to use a real profiler or memory debugger. As an admin in the past, the same problem manifested itself as a lack of real database support. Mainstream Linux acceptance fixed that particular problem and will soon fix my dev tool problem, so I can EBay this silly Sun box.
Secondly, there are thousands of IT professionals out there that want to employ Linux to solve their problems --- because Linux is almost always the best solution for server problems. However, the stigma Linux has (and is only starting to get over) prevents them from doing so. These people are forced by management to employ legacy NT and Novell solutions instead.
It also solidifies Microsoft's position in the market --- and we all know what happens to any market Microsoft controls. I don't think Dan Bernstein would be in any position to realistically replace BIND if Microsoft owned DNS. The only thing keeping infrastructure protocols even remotely accessible is the IT community's acceptance of Unix as a superior server solution.
Lots of things are "useful" and don't have buzz. Things like 486 DNS servers and Cisco CGS routers. But I don't want to use Linux on my scraped- together home network to save cash. I want to build my products on it and deploy it in my company's infrastructure because it is vastly superior to the alternatives that are available to me.
Linux may not be a "business" issue for you, but it is for me. If Linux "fails" and becomes like NetBSD (useful, but useless), I'm going to be upset. As will a lot of other people who don't want to spend their careers working with legacy proprietary closed-source nonsense.
I'm going to refrain from discussing ESR's personality, ego, or station within the open source "movement". I do not know ESR and thus can only evaluate him by the words he chooses to represent himself with.
Has anyone else noticed that the following statement from ESR's response article:
... I have made a point of not gratuitously waving my policitcs around in my papers...
... contrasts rather starkly with ESR's actual writings? For instance, have a look at ESR's "acceptance speech" , delivered upon receiving, on behalf of the entire Open Source movement, an award from the CPSR:
... All too often, people who invoke 'social responsibility' are demanding that we give up individual liberty -- that we accept just a bit more taxation, just a bit more regulation, just a bit more government intrusiveness, all for the supposed good of society...
... this paper goes on to claim that a "socially responsible" programmer must never become involved in projects that aid firearms regulation.
Regardless of whether I agree or disagree with ESR's political beliefs, I find it questionable that ESR has any business taking umbrage at the notion of questioning those beliefs. He has made a point of injecting those beliefs into his discussions of open source, and he is acting as a representative for this community.
Personally, I think that makes criticisms of the consistancy, logical foundation, and appropriateness of his politics fair game in this discussion.
IPv4 addresses have no accountability because they aren't authenticated. While it is possible to "trace" an IP address to its source in real- time in some circumstances, doing so is nowhere nearly as simple as you're making it out to be.
The obvious issue here is address spoofing, since nothing prevents an attacker from sending out a packet with an arbitrary source address. While there are issues with doing "full duplex" spoofed transactions (the Internet will normally route the responses back to their true source), this is not an unsolveable technical problem.
There has been work done in the recent past to faciliate traceability of unauthenticated IP packets. The insight is that you can trust the routers (at some level in the routing hierarchy). The routers can identify and cache the interface on which each distinct IP address arrives. You then just need a recursive query protocol to trace the address backwards hop-by-hop until you get a reasonable approximation of where the address entered the system.
But if the point that you're making is that the privacy impact of IPv6 address assignment schemes are irrelevant because you have no privacy NOW, I agree wholeheartedly. Anonymous forwarding/ proxy systems are the way to go; the amount of work it takes to make a truely anonymous network is significant, and neither IPv4 nor IPv6 does anything to address that.
Linux, and UNIX systems in general, do have a very real security problem owing from their architectural dependance on the "root" superuser. While "sudo" does superficially mitigate the risks of giving all administrators "full root access", it does so in a manner that is fairly questionable (it effectively creates limited-access SUID programs out of programs that were not designed to be SUID).
But administrative access aside, the whole idea of the "root" user is bad, and has been acknowledged as bad. The problem is that the system both expresses privilege in a more-or-less "binary" fashion (all or none) and also requires that the "all" privilege be exposed to normal users from time to time (SUID programs and root-owned daemon processes.
A better design for a secure operating system is to utilize a different "privilege" or "capability" for each privileged operation. For instance, where Linux relies on "root" to signify the privilege needed to open a raw socket, a better system would use a "raw socket" privilege.
The end result of this approach is that instead of SUID "root" "ping" programs (for example), you have "raw-socket privileged" programs. The obvious benefit is that if you find a security flaw in the "ping" program, the attacker only gets the ability to open a raw socket, not the entire system.
While this is a real flaw in the Linux/UNIX security model, I am unconvinced that the Win32 security model is much better. Win32 also has an omnipriveleged superuser ("Administrator"). What's worse, Win32 systems have a terrible multi-user design, which also compromises security.
And I am absolutely unconvinced that Win32 is even comparable to Linux in terms of real security, since Win32 is a large, closed- source software project with a demonstrated history of stupid bugs (poor input validation, etc). In the open-source Unix community, a new class of "stupid bug" is followed by a period in which code is swept through in an attempt to eradicate those bugs. There is no evidence to suggest that the same process occurs in Win32.
However, it would be unfortunate if dogmatic allegience to Linux prevented people from acknowledging its more serious flaws.
Without commenting on any of the rest of the Microsoft/Linux article, I want to point one simple fact out:
Security bugs get found at varying times. Even in the OpenBSD audit (arguably the largest single source-code security audit ever done), security bugs were found days, weeks, and even months apart. It is simply, and obviously, not possible to find "all" the security flaws in a complex piece of software all at once.
Thus, it is obvious that a maximally secure operating system will correct security flaws piecemeal, as they are discovered. There is no way to provide for an "all-emcompassing" security patch kit or Service Pack without delaying fixes. Delaying fixes very obviously hurts the end-user and substantially decreases security.
Having worked closely with Microsoft in the past to facilitate correction and disclosure of security problems, I can state with confidence that Microsoft's approach to dealing with new security problems is not only not modern, but also deceptive and ineffecient. As is the case with most commercial software vendors, Microsoft is slow to acknowledge problems and even slower to fix them. Microsoft is the archetypical slimy vendor when it comes to security issues.
However, my anecdotal evidence of Microsoft's poor security posture pales in comparison to the evidence Microsoft itself gives when it advises potential customers that the "Service Pack" approach to security is superior to the open-source standard of full disclosure and near-instantaneous repair.
What a silly gripe. Sendmail is open source software. If you want a pretty, useable front end to it, write one. All the documentation and design details you need to do so are right there.
I don't understand how you can criticize an organization simply because they didn't write something you want (in this case, a free open source Sendmail front end).
I think this is an excellent move on Sendmail's part, and one that other vendors might do well to mimic.
First, from an "ethical" perspective: NT is a closed-source proprietary operating system. The expectation that you'll get quality open-source apps on NT is and should be unrealistic. It is easier to create open-source software in an open environment, and that's exactly what Linux and BSD provides.
Moreover, because of the closed nature of NT, it is more of an investment to get software working "natively" on NT than under Linux (where almost any task you'd want to do has been done and a high-quality example has been published). Sendmail is just "protecting their investment", an action necessitated by Microsoft's strategy of using closed proprietary APIs. Another reason for IT people NOT to lock themselves into Microsoft's proprietary solutions.
Now, from a business perspective: Win32 is where the money is right now. If Sendmail can pick up good revenue from selling their product closed under NT, they'll have less incentive to keep their extensions closed under Linux. This may be the best of both worlds --- they can keep the goodwill of the Linux community by distributing open software there, but make money by charging people to use it under NT.
It seems like an interesting alternative open- source business model to me. Why haven't more people discussed this as a way of making money off open source development?
It looks to me like the concerns most people have about this article are:
- The apparent double standard being shown, where journalists apparently expect to have an amount of access to Linus Torvalds that they don't expect from other companies.
- The fact that this "new media buffer" around Linus Torvalds was deemed "newsworthy", when there's no solid evidence that Linus has a new policy, and when such a media buffer is totally reasonable, given that Linus isn't "Linux PR" full-time.
L0pht predates "skript kiddies". The researchers at the L0pht are among the more respected in the whole security industry (speaking as one who spent a great deal of time in that industry). They're responsible for a good deal of pioneering work, and they have a reputation for doing things right.
Which is what I believe they are doing here, by thoroughly documenting the way their tool works and what its limitations are. We can study their tool and determine through peer-review how effective it is. And, if we wanted to, we could use their research to build our own tools.
Which is only fair, because they are also using publically available research to build their tool.
A.) The "company" you're talking about never published any research. They might as well have never done it.
B.) Your idea of how the L0pht tool works has very little to do with what the tool actually does. The technique your "company" uses (which is well-known, though undocumented) is not the only (or even the most powerful) check done by the L0pht tool.
C.) Physical sniffers are not the threat that this tool purports to defend against, nor are they a threat for the vast majority of networks (in which physical access to the network is not an issue).
More wrong-headed "conventional" wisdom. The act of measuring network traffic on a general- purpose platform produces changes in that platform. These changes are detectable.
Promiscuous mode sniffing alters the way the Ethernet drivers work, it changes the performance characteristics of the whole network system, and it causes the platform to react to events it wouldn't normally react to.
Common sense tells us that unless there's no way to talk to the sniffing machine and thus no way to take measurements, running a naieve (read, not sniffer-sniffer-protected) sniffer is going to change SOMETHING on the box we can detect.
If the machine runs a general-purpose operating system and has "legitimate" network connectivity, the presence of a promiscuous-mode sniffer on the box will be detectable (not necessarilly by AntiSniff --- I'm not very familiar with how effective their implementation is) with latency analysis.
This only works against a small number of broken stacks. When we (Secure Networks, Inc) discovered this technique several years ago, it only worked reliably against Linux and SunOS (Ivan Arce, the guy who came up with this idea, could tell you better). Since then, operating systems have gotten better about back-checking Ethernet addresses in their drivers.
If you look at the AntiSniff material, this is one of the checks they perform, and its limitations are well-documented.
In the real world, IPsec isn't a practical solution to most security problems. When the entire Internet speaks IPsec, you will have a valid point. Until then, LAN snooping is a problem that is important to address.
Even when IPsec is deployed widely, the only reasons sniffing will cease to be such an issue is that so few people will be doing it anymore. Right now, sniffer detection is a valuable means of detecting _intrusions_, and after-the-fact intrusion detection is obviously valuable when you can't assure attack detection.
More wrong-headed "conventional wisdom". The two flaws in the logic that "switches solve sniffing": A.) switches aren't designed for security (even the ones with "security features"), and B.) there are things you can do at the network layer that affect the way the link layer works.
There are switches that will revert into an "insecure" forwarding mode when room for forwarding tables runs out (if you think about this, you'll realize that there's basically no way any switch can prevent this attack, other than detecting it and locking down the offending port). There are switches that can be "fooled" by seeing a frame with an Ethernet address it believes to be on a different port (forwarding table updates happen instantaneously). There are tens of other little problems like this that can be exploited.
More importantly, there are games you can play with IP that completely subvert switches; you can race ARP, for instance, and transparently forward captures packets. You can play games with dynamic routing. Look at the recent L0pht advisory on Router Discovery.
For something to be useful as a security device, it needs to provide some degree of assurance that it is doing what you expect it to be doing. Switches, as "anti-sniffing" devices, fail this test --- there is no way for you to know, outside of expensive testing, not only of the switch but of your entire LAN environment, whether or not they are really providing any protection.
This always seems to be the conventional knee- jerk reaction to sniffer protection. Obviously, it is impossible to detect with software the presence of a "hardware" sniffer. People who insist on pointing this out repeatedly miss the point: the overwhelming vast majority of malicious sniffers are software, installed on general- purpose computers.
A general technique to detect such sniffers would have a dramatic beneficial effect.
A modified Linux kernel is easy to detect, but not with "md5". Read the source code. md5 does an open() on the target file. It is trivially easy to hook open() in the kernel, detect attempts to read "vmlinuz", and return the original file instead of the modified one.
Poof. Perfect looking signature and you didn't even have to cryptanalyze MD5. What a break!
In those cases, "less" invisible. Both of those (old) tricks are incredibly easy to get past.
Re: "ps": keep a backup copy of "ps" somewhere and periodically diff the -ax output against that of the "real" ps. If they differ, panic.
Re: "ls": keep a backup copy of "ls" somewhere and periodically diff the -lua output against that of the "real" ls. If they differ, panic.
There's a procedure to discover attempts at hiding things on Unix systems for any trick an attacker uses. Regardless of how low-level the attacker puts her trojan.
Releasing the exploit for the ISS overflow did not make a bad problem worse. It would have been impossible to make the problem any worse than it already was: Remote administrative access via an extremely popular, very public network service, and it was already being exploited in the underground.
At that point, no amount of information that could have been released to the public could do anything but help.
It's unfortunate, but predictable, that a community of users and vendors, not accustomed to handling security problems professionally, could do nothing but resorting to pointing fingers and shooting the messenger.
1.) Sir Dystik and Dildog did hack on their own machines. All they're doing is publishing the results.
2.) The fact that an "administration tool" can be used for nefarious purposes does not make it any less of an administration tool. Netcat, inetd, and the GNU C compiler are all used by crackers.
3.) Anyone who suggests CMU CERT (or any FIRST organization) as an avenue for disclosing security holes has never dealt with CERT or FIRST. CERTs automatic reaction to being presented with a new security problem is to consult the affected vendor. CERT releases nothing without the approval of the affected vendors.
CERT, and more importantly the public's idea of CERT's role, is a major problem with the security community today.
4.) If cDc released a "crippled" version of BO2K, Microsoft would immediately reply by claiming to the press that the issue was "theoretical" and "harmless" to normal users. That would defeat the purpose of releasing BO2K.
5.) I don't understand how you can, with a straight face, compare someone who killed hundreds of people with two people who wrote and published code. This is offensive on many levels.
6.) It takes a very naieve perspective on the security community to assume that a "benign" disclosure of a security hole will provoke any action from Microsoft or any other corporate software vendor. Having dealt directly with Microsoft in a security hole disclosure, I can state with confidence that Microsoft's primary goal is NOT to responsibly notify the public as quickly as possible.
The whole idea behind BO2K is an elaborate attempt to call Microsoft's bluff (that the problems BO takes advantage of don't affect MS's flagship operating system, that any problems that do affect NT are simply theoretical, and that nobody really exploits problems on NT, unlike under Unix).
There wouldn't be an issue if Microsoft was honest about the issues affecting its products. The same issues affect Linux, but they are for the most part acknowledged and dealt with. Thus, there's really not much fun in poking holes in Linux.
cDc hasn't invented anything. The source code is meaningless to the research community as a document of any new problems.
cDc probably hasn't done anything in the code for BO2K that wasn't already documented in MSDN. The source code probably will not convey any new revelations to the computer underground.
BO2K is not a new concept. The equivalent has probably been floating around the computer underground for ages. The idea is simply much better documented now, and MS has a very compelling reason to address the issue directly.
It is a fairly well-accepted tenet of the security community that whenever you hear about new source code being released, you should assume it HAS been released to the underground for quite some time beforehand. What makes you think that BO2K, or something much worse, hasn't been available to modify by crackers for years?
This same logic could be applied to Aleph One's "Smashing the Stack" paper (the harbinger of 31336 different stack overflow exploits). With the benefit of hindsight, we see that the result of this exploit cookbook (which was, by the way, far more dangerous than BO2K source code, given that it [and it's immediate antecedants] DID contain revelations to the computer underground) was the almost complete eradication of stack overflows from Linux and 4.4BSD.
On a lesser scale, the release of the rootkit trojans had the same effect for the Unix security community --- you'd have a hard time hiding the original rootkit on even a naievely administrated network these days.
Do you honestly think there's anything that Back Orifice does that Microsoft Engineering doesn't already know? I have met and talked to Sir Dystik on a number of occasions, and my impression of him is that he is someone who knows what a "security advisory" is and what the conventions are (prerelease to vendor, publication of a patch/workaround, etc) for releasing them.
This ISN'T a new security hole. cDc doesn't need to teach Microsoft ANYTHING. This is a a statement (IMO, an effective one) to the public about the security implications of OTHER, WELL KNOWN Win32 security problems. They are, to co-opt the motto of the L0pht, "making the theoretical practical".
This is a good thing. You can show all the scary press about BO2K to your IT managers and get resources to properly secure your NT boxes. You should appreciate (and exploit) this.
Slashdot Mirror
Congestion control was developed in response to a congestion *crisis* in the late 1980s. Proper congestion control is a requirement for the Internet to function. The LACK of congestion control is common streaming and multicast protocols is a commonly cited major hurdle for the deployment of multicast applications on the Internet.
It's been a nightmare scenario for awhile now that Microsoft (they of the "transient failure" RST packet) would unscrupulously try to gain a competitive advantage by manipulating congestion control. By "breaking the rules" they could make a faster stack. Another scary thought is that silly "Internet Accelerator" products could actually sell REAL accelerators, that provide horsepower boosts at the expense of the entire network.
What you DON'T want to see happen is for Linux to gain "turbocharging" via congestion-ignorance. What that does is set up an arms race between Linux and every other stack vendor, and particularly Microsoft. That arms race could easily lead to congestion collapse and yet another Internet scaleability crisis.
What Stefan Savage is describing are VULNERABILITIES in common TCP/IP stacks. They need to be fixed, and programs that take advantage of them need to be considered in the same light as programs that get rid of pesky security measures on remote computers --- as exploits.
Just chiming in here, because I think it's odd that people here are paying more attention to the clever backtracking hack Savage came up with and less attention to the important, new security vulnerabilities he has documented.
We can debate the morality of nondisclosure ad nauseum. I'm more interested in engineering than morality --- and the fact of the matter is that policies that discourage full and open disclosure DO NOT WORK. They hinder the discovery of important security flaws and create an environment in which black hats have a significant advantage over white hats. Remember, the black hats don't give a damn about Mozilla's disclosure policies, and history tells us that they tend to find the problems first.
Nondisclosure has (dubious) practical benefits for tightly-guarded closed projects. Mozilla obviously doesn't qualify, and the idea that security flaws in Mozilla's open codebase can be meaningfully hidden is ludicrous.
As this is a Slashdot story, I don't trust the veracity of the claims that Mozilla is going to try to hide security information. However, if, contrary to the established best practices in the security community, they decide to go ahead with some sort of Mozilla "inner circle", they are going to give a nice black eye to Open Source's security argument.
As a Linux software developer and a longtime free software user, I totally disagree with what you're saying and agree wholeheartedly with what the Globe article says. Mainstream acceptance of Linux and application support for the platform is more important than you seem to know, and I'd like to tell you why.
First and foremost, we need to move away from the notion that "applications" equal games and word processors. As a developer, it annoys (and costs) me that I have to maintain a Solaris or Win32 dev box in order to use a real profiler or memory debugger. As an admin in the past, the same problem manifested itself as a lack of real database support. Mainstream Linux acceptance fixed that particular problem and will soon fix my dev tool problem, so I can EBay this silly Sun box.
Secondly, there are thousands of IT professionals out there that want to employ Linux to solve their problems --- because Linux is almost always the best solution for server problems. However, the stigma Linux has (and is only starting to get over) prevents them from doing so. These people are forced by management to employ legacy NT and Novell solutions instead.
It also solidifies Microsoft's position in the market --- and we all know what happens to any market Microsoft controls. I don't think Dan Bernstein would be in any position to realistically replace BIND if Microsoft owned DNS. The only thing keeping infrastructure protocols even remotely accessible is the IT community's acceptance of Unix as a superior server solution.
Lots of things are "useful" and don't have buzz. Things like 486 DNS servers and Cisco CGS routers. But I don't want to use Linux on my scraped- together home network to save cash. I want to build my products on it and deploy it in my company's infrastructure because it is vastly superior to the alternatives that are available to me.
Linux may not be a "business" issue for you, but it is for me. If Linux "fails" and becomes like NetBSD (useful, but useless), I'm going to be upset. As will a lot of other people who don't want to spend their careers working with legacy proprietary closed-source nonsense.
Please don't pretend to speak for us.
Has anyone else noticed that the following statement from ESR's response article:
Regardless of whether I agree or disagree with ESR's political beliefs, I find it questionable that ESR has any business taking umbrage at the notion of questioning those beliefs. He has made a point of injecting those beliefs into his discussions of open source, and he is acting as a representative for this community.
Personally, I think that makes criticisms of the consistancy, logical foundation, and appropriateness of his politics fair game in this discussion.
IPv4 addresses have no accountability because
they aren't authenticated. While it is possible
to "trace" an IP address to its source in real-
time in some circumstances, doing so is nowhere
nearly as simple as you're making it out to be.
The obvious issue here is address spoofing, since
nothing prevents an attacker from sending out
a packet with an arbitrary source address. While
there are issues with doing "full duplex" spoofed
transactions (the Internet will normally route the
responses back to their true source), this is
not an unsolveable technical problem.
There has been work done in the recent past to
faciliate traceability of unauthenticated IP
packets. The insight is that you can trust the
routers (at some level in the routing hierarchy).
The routers can identify and cache the interface
on which each distinct IP address arrives. You
then just need a recursive query protocol to
trace the address backwards hop-by-hop until you
get a reasonable approximation of where the
address entered the system.
But if the point that you're making is that the
privacy impact of IPv6 address assignment schemes
are irrelevant because you have no privacy NOW,
I agree wholeheartedly. Anonymous forwarding/
proxy systems are the way to go; the amount of
work it takes to make a truely anonymous network
is significant, and neither IPv4 nor IPv6
does anything to address that.
Re "sudo":
Linux, and UNIX systems in general, do have
a very real security problem owing from their
architectural dependance on the "root"
superuser. While "sudo" does superficially
mitigate the risks of giving all administrators
"full root access", it does so in a manner
that is fairly questionable (it effectively
creates limited-access SUID programs out of
programs that were not designed to be SUID).
But administrative access aside, the whole idea
of the "root" user is bad, and has been
acknowledged as bad. The problem is that the
system both expresses privilege in a more-or-less
"binary" fashion (all or none) and also
requires that the "all" privilege be exposed to
normal users from time to time (SUID programs
and root-owned daemon processes.
A better design for a secure operating system is
to utilize a different "privilege" or "capability"
for each privileged operation. For instance,
where Linux relies on "root" to signify the
privilege needed to open a raw socket, a better
system would use a "raw socket" privilege.
The end result of this approach is that instead
of SUID "root" "ping" programs (for example), you
have "raw-socket privileged" programs. The
obvious benefit is that if you find a security
flaw in the "ping" program, the attacker only
gets the ability to open a raw socket, not the
entire system.
While this is a real flaw in the Linux/UNIX
security model, I am unconvinced that the Win32
security model is much better. Win32 also has
an omnipriveleged superuser ("Administrator").
What's worse, Win32 systems have a terrible
multi-user design, which also compromises
security.
And I am absolutely unconvinced that
Win32 is even comparable to Linux in terms of
real security, since Win32 is a large, closed-
source software project with a demonstrated
history of stupid bugs (poor input validation,
etc). In the open-source Unix community, a new
class of "stupid bug" is followed by a period
in which code is swept through in an attempt to
eradicate those bugs. There is no evidence to
suggest that the same process occurs in Win32.
However, it would be unfortunate if dogmatic
allegience to Linux prevented people from
acknowledging its more serious flaws.
Security bugs get found at varying times. Even in the OpenBSD audit (arguably the largest single source-code security audit ever done), security bugs were found days, weeks, and even months apart. It is simply, and obviously, not possible to find "all" the security flaws in a complex piece of software all at once.
Thus, it is obvious that a maximally secure operating system will correct security flaws piecemeal, as they are discovered. There is no way to provide for an "all-emcompassing" security patch kit or Service Pack without delaying fixes. Delaying fixes very obviously hurts the end-user and substantially decreases security.
Having worked closely with Microsoft in the past to facilitate correction and disclosure of security problems, I can state with confidence that Microsoft's approach to dealing with new security problems is not only not modern, but also deceptive and ineffecient. As is the case with most commercial software vendors, Microsoft is slow to acknowledge problems and even slower to fix them. Microsoft is the archetypical slimy vendor when it comes to security issues.
However, my anecdotal evidence of Microsoft's poor security posture pales in comparison to the evidence Microsoft itself gives when it advises potential customers that the "Service Pack" approach to security is superior to the open-source standard of full disclosure and near-instantaneous repair.
software. If you want a pretty, useable front
end to it, write one. All the documentation
and design details you need to do so are right
there.
I don't understand how you can criticize an
organization simply because they didn't write
something you want (in this case, a free open
source Sendmail front end).
part, and one that other vendors might do well
to mimic.
First, from an "ethical" perspective: NT is a
closed-source proprietary operating system. The
expectation that you'll get quality open-source
apps on NT is and should be unrealistic. It is
easier to create open-source software in an open
environment, and that's exactly what Linux and
BSD provides.
Moreover, because of the closed nature of NT, it
is more of an investment to get software working
"natively" on NT than under Linux (where almost
any task you'd want to do has been done and a
high-quality example has been published). Sendmail
is just "protecting their investment", an action
necessitated by Microsoft's strategy of using
closed proprietary APIs. Another reason for IT
people NOT to lock themselves into Microsoft's
proprietary solutions.
Now, from a business perspective: Win32 is where
the money is right now. If Sendmail can pick up
good revenue from selling their product closed
under NT, they'll have less incentive to keep
their extensions closed under Linux. This may
be the best of both worlds --- they can keep the
goodwill of the Linux community by distributing
open software there, but make money by charging
people to use it under NT.
It seems like an interesting alternative open-
source business model to me. Why haven't more
people discussed this as a way of making money
off open source development?
It looks to me like the concerns most people
have about this article are:
- The apparent double standard being shown,
where journalists apparently expect to have
an amount of access to Linus Torvalds that
they don't expect from other companies.
- The fact that this "new media buffer" around
Linus Torvalds was deemed "newsworthy", when
there's no solid evidence that Linus has a
new policy, and when such a media buffer is
totally reasonable, given that Linus isn't
"Linux PR" full-time.
It looks to me like the concerns most people
have about this article are:
L0pht predates "skript kiddies". The researchers
at the L0pht are among the more respected in the
whole security industry (speaking as one who spent
a great deal of time in that industry). They're
responsible for a good deal of pioneering work,
and they have a reputation for doing things right.
Which is what I believe they are doing here, by
thoroughly documenting the way their tool works
and what its limitations are. We can study their
tool and determine through peer-review how
effective it is. And, if we wanted to, we could
use their research to build our own tools.
Which is only fair, because they are also using
publically available research to build their
tool.
A.) The "company" you're talking about never
published any research. They might as well have
never done it.
B.) Your idea of how the L0pht tool works has
very little to do with what the tool actually
does. The technique your "company" uses (which
is well-known, though undocumented) is not the
only (or even the most powerful) check done by
the L0pht tool.
C.) Physical sniffers are not the threat that
this tool purports to defend against, nor are
they a threat for the vast majority of networks
(in which physical access to the network is not
an issue).
More wrong-headed "conventional" wisdom. The
act of measuring network traffic on a general-
purpose platform produces changes in that
platform. These changes are detectable.
Promiscuous mode sniffing alters the way the
Ethernet drivers work, it changes the performance
characteristics of the whole network system, and
it causes the platform to react to events it
wouldn't normally react to.
Common sense tells us that unless there's no
way to talk to the sniffing machine and thus no
way to take measurements, running a naieve (read,
not sniffer-sniffer-protected) sniffer is going
to change SOMETHING on the box we can detect.
If the machine runs a general-purpose operating
system and has "legitimate" network connectivity,
the presence of a promiscuous-mode sniffer on the
box will be detectable (not necessarilly by
AntiSniff --- I'm not very familiar with how
effective their implementation is) with latency
analysis.
This only works against a small number of broken
stacks. When we (Secure Networks, Inc) discovered
this technique several years ago, it only worked
reliably against Linux and SunOS (Ivan Arce, the
guy who came up with this idea, could tell you
better). Since then, operating systems have gotten
better about back-checking Ethernet addresses in
their drivers.
If you look at the AntiSniff material, this is one
of the checks they perform, and its limitations
are well-documented.
In the real world, IPsec isn't a practical
solution to most security problems. When the
entire Internet speaks IPsec, you will have
a valid point. Until then, LAN snooping is a
problem that is important to address.
Even when IPsec is deployed widely, the only
reasons sniffing will cease to be such an issue
is that so few people will be doing it anymore.
Right now, sniffer detection is a valuable means
of detecting _intrusions_, and after-the-fact
intrusion detection is obviously valuable when
you can't assure attack detection.
More wrong-headed "conventional wisdom". The two
flaws in the logic that "switches solve sniffing":
A.) switches aren't designed for security (even
the ones with "security features"), and B.) there
are things you can do at the network layer that
affect the way the link layer works.
There are switches that will revert into an
"insecure" forwarding mode when room for
forwarding tables runs out (if you think about
this, you'll realize that there's basically no
way any switch can prevent this attack, other
than detecting it and locking down the offending
port). There are switches that can be "fooled"
by seeing a frame with an Ethernet address it
believes to be on a different port (forwarding
table updates happen instantaneously). There
are tens of other little problems like this that
can be exploited.
More importantly, there are games you can play
with IP that completely subvert switches; you can
race ARP, for instance, and transparently forward
captures packets. You can play games with dynamic
routing. Look at the recent L0pht advisory on
Router Discovery.
For something to be useful as a security device,
it needs to provide some degree of assurance that
it is doing what you expect it to be doing.
Switches, as "anti-sniffing" devices, fail this
test --- there is no way for you to know, outside
of expensive testing, not only of the switch but
of your entire LAN environment, whether or not
they are really providing any protection.
This always seems to be the conventional knee-
jerk reaction to sniffer protection. Obviously,
it is impossible to detect with software the
presence of a "hardware" sniffer. People who
insist on pointing this out repeatedly miss the
point: the overwhelming vast majority of malicious
sniffers are software, installed on general-
purpose computers.
A general technique to detect such sniffers would
have a dramatic beneficial effect.
A modified Linux kernel is easy to detect, but
not with "md5". Read the source code. md5 does
an open() on the target file. It is trivially
easy to hook open() in the kernel, detect attempts
to read "vmlinuz", and return the original file
instead of the modified one.
Poof. Perfect looking signature and you didn't
even have to cryptanalyze MD5. What a break!
In those cases, "less" invisible. Both of
those (old) tricks are incredibly easy to
get past.
Re: "ps": keep a backup copy of "ps" somewhere
and periodically diff the -ax output against
that of the "real" ps. If they differ, panic.
Re: "ls": keep a backup copy of "ls" somewhere
and periodically diff the -lua output against
that of the "real" ls. If they differ, panic.
There's a procedure to discover attempts at
hiding things on Unix systems for any trick an
attacker uses. Regardless of how low-level the
attacker puts her trojan.
Releasing the exploit for the ISS overflow
did not make a bad problem worse. It would have
been impossible to make the problem any worse
than it already was: Remote administrative
access via an extremely popular, very public
network service, and it was already being
exploited in the underground.
At that point, no amount of information that could
have been released to the public could do anything
but help.
It's unfortunate, but predictable, that a
community of users and vendors, not accustomed
to handling security problems professionally,
could do nothing but resorting to pointing fingers
and shooting the messenger.
Point by point:
1.) Sir Dystik and Dildog did hack on their own
machines. All they're doing is publishing the
results.
2.) The fact that an "administration tool" can
be used for nefarious purposes does not make it
any less of an administration tool. Netcat, inetd,
and the GNU C compiler are all used by crackers.
3.) Anyone who suggests CMU CERT (or any FIRST
organization) as an avenue for disclosing security
holes has never dealt with CERT or FIRST. CERTs
automatic reaction to being presented with a new
security problem is to consult the affected
vendor. CERT releases nothing without the approval
of the affected vendors.
CERT, and more importantly the public's idea of
CERT's role, is a major problem with the security
community today.
4.) If cDc released a "crippled" version of BO2K,
Microsoft would immediately reply by claiming to
the press that the issue was "theoretical" and
"harmless" to normal users. That would defeat the
purpose of releasing BO2K.
5.) I don't understand how you can, with a
straight face, compare someone who killed hundreds
of people with two people who wrote and published
code. This is offensive on many levels.
6.) It takes a very naieve perspective on the
security community to assume that a "benign"
disclosure of a security hole will provoke any
action from Microsoft or any other corporate
software vendor. Having dealt directly with
Microsoft in a security hole disclosure, I can
state with confidence that Microsoft's primary
goal is NOT to responsibly notify the public as
quickly as possible.
The whole idea behind BO2K is an elaborate attempt
to call Microsoft's bluff (that the problems BO
takes advantage of don't affect MS's flagship
operating system, that any problems that do affect
NT are simply theoretical, and that nobody really
exploits problems on NT, unlike under Unix).
There wouldn't be an issue if Microsoft was honest
about the issues affecting its products. The same
issues affect Linux, but they are for the most
part acknowledged and dealt with. Thus, there's
really not much fun in poking holes in Linux.
cDc hasn't invented anything. The source code
is meaningless to the research community as a
document of any new problems.
cDc probably hasn't done anything in the code
for BO2K that wasn't already documented in MSDN.
The source code probably will not convey any
new revelations to the computer underground.
BO2K is not a new concept. The equivalent has
probably been floating around the computer
underground for ages. The idea is simply much
better documented now, and MS has a very
compelling reason to address the issue directly.
It is a fairly well-accepted tenet of the
security community that whenever you hear about
new source code being released, you should assume
it HAS been released to the underground for
quite some time beforehand. What makes you think
that BO2K, or something much worse, hasn't been
available to modify by crackers for years?
This same logic could be applied to Aleph One's
"Smashing the Stack" paper (the harbinger of
31336 different stack overflow exploits). With
the benefit of hindsight, we see that the result
of this exploit cookbook (which was, by the way,
far more dangerous than BO2K source code, given
that it [and it's immediate antecedants] DID
contain revelations to the computer underground)
was the almost complete eradication of stack
overflows from Linux and 4.4BSD.
On a lesser scale, the release of the rootkit
trojans had the same effect for the Unix security
community --- you'd have a hard time hiding the
original rootkit on even a naievely administrated
network these days.
BO2K will have the same effect on NT.
Do you honestly think there's anything that
Back Orifice does that Microsoft Engineering
doesn't already know? I have met and talked
to Sir Dystik on a number of occasions, and
my impression of him is that he is someone who
knows what a "security advisory" is and what
the conventions are (prerelease to vendor,
publication of a patch/workaround, etc) for
releasing them.
This ISN'T a new security hole. cDc doesn't need
to teach Microsoft ANYTHING. This is a a statement
(IMO, an effective one) to the public about the
security implications of OTHER, WELL KNOWN
Win32 security problems. They are, to co-opt the
motto of the L0pht, "making the theoretical
practical".
This is a good thing. You can show all the scary
press about BO2K to your IT managers and get
resources to properly secure your NT boxes. You
should appreciate (and exploit) this.