By going after the end users they can create clarity in the courts because the end users probably won't put up a defence like IBM or RedHat would. They simply wouldn't be able to afford the legal bill.
And usually, these end users can sue their vendors in turn.
This creates a massive distributed attack on the vendors. In Germany, there was already a case remotely like this (it involved trademark infringement), and a court ruled that it going after end users to create preasure on a specific vendor is illegal.
Re:DNSSEC needn't be a panacea to be useful.
on
DNSSEC: Good Enough?
·
· Score: 2, Informative
DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism, whereby a cartel of ~5 companies with keys that got into the original Netscape release essentially rule the roost, because Joe Average has no idea how to install a new root key in his browser. The cheapest key of this type will cost you ~$150 per year, and you can't use it to make more keys.
A browser key costs $250,000 per year, and $250,000 up front for audits etc., AFAIK.
I think the problem here is liability. If a software glitch caused objects to vanish, or improvements to the game shifted the balance and (inadvertedly) change the value of items, people would suddenly lose real money, and might sue.
This is exactly my point. Marcelo just doesn't care about security issues (look at the release cycles). You should run vendor kernels on production machines, not the kernel.org version (that's the public opinion of quite a few influential kernel developers!).
However, this solves only part of the problem. Since there is no central source of security-related information, we are fully hit by the Chinese Whisper phenomenon.
For example, Red Hat wrote in their advisory:
CAN-2003-0552: Jerry Kreuscher discovered that the Forwarding table could be spoofed by sending forged packets with bogus source addresses the same as the local host.
"Forwarding table" could mean that IP forwarding is affected, but Debian writes:
Linux 2.4.x allows remote attackers to spoof the bridge forwarding table via forged packets whose source addresses are the same as the target.
So who's right? Are you safe if you don't run bridging (and maybe just IP forwarding), or are you still vulnerable?
I guess we'll just have to disagree. I think that, in comparison, Linux advisories tend to be much better. The fixes are even better because i can tell before applying exactly what the impact will be, and whether or not the fix actually fixes the underlying problem or just a symptom.
Quote from a recent Debian advisory on phpgroupware:
- CAN-2003-0599: Unknown vulnerability in the Virtual File System
(VFS) capability for phpGroupWare 0.9.16preRC and versions before
0.9.14.004 with unknown implications, related to the VFS path being
under the web document root.
Quite helpful, eh?
The only reason we aren't completely lost is the availability of source code patches. However, how many shops which run Linux have employees with the skills and knowledge necessary to quickly analyze source code and recommend how to proceed?
Do you really think that Microsoft publishes security advisories for kernel problems that others don't point out and make public? The one you referenced was specifically referencing a third party which notified them. The Linux community also issues advisories for widely-known kernel issues as well.
Only true if you define "widely known" to mean "we issued an advisory".
Alan Cox won't reveal anything about kernel security out of fear of the DMCA.
He can use an anonymous remailer if he wants to publish verifiable information about security vulnerabilities. But Alan is neither the Linux Security Czar, nor does he maintain 2.4.x.
However, it's true that publishing detailed vendor security advisories results in significant legal risks for the vendor. For software, it appears to be easy to exclude any warranties, but not for documents describing its behavior. But guess what? Microsoft is now willing to take such risks to protect customers. Why shouldn't Red Hat do the same?
Most of the published insecurities with either system are in the libraries or applications, not the kernel.
This certainly doesn't exempt developers from handling security issues if they arise anyway. There are still enough security issues in the kernel, and the maintainers should have gained some experience in dealing with it.
But the kernel is just symptomatic for the whole system. Many subprojects aren't much better. Some do not bother to issue any advisories at all, some prefer very cryptic ones (BIND, Apache, OpenSSH). Sometimes, there are shining exceptions, such as recent Postfix advisory (however regrettable its necessity might be). Everything's there, especially how to tell if you are vulnerable, and how to apply countermeasures without changing the software itself. Compare it with the advisory from Red Hat.
With their new mentality, everyone will say, "so why should we bother with Microsoft when we can go a more open and cheaper route?"
Yes, this is another way things could turn out.
"Right now, their advisories are already among the best the market offers"
Hahahahahahahahahahahaha!!!!!!!!!!
Actually, this isn't funny. It certainy shows that something is wrong. But at the moment, Microsoft easily outperforms Red Hat, SuSE and all the commercial UNIX vendors. And have you ever seen a Linux advisory (i.e. for the kernel itself)? Only the Netfilter maintainers seem to release them for their subsystem.
Most linux/bsd distros default config are quite secure, whereas the default in Windows (which most people use) is extremely open and very vulnerable.
This is true at the moment, but it's changing with new product releases.
For example, on Windows Server 2003, IIS is not installed by default, and if you install it, it binds to localhost only by default. I find this rather impressive for Microsoft because it shows that the company sacrifices trivial installation for more security. I wonder where they are heading. IMHO, it's getting more and more likely that Microsoft crushes the free software competition in the security area. Not because of certification, but because of more reliable software, better product management, courage to make decisions which inconvenience users etc. Right now, their advisories are already among the best the market offers (which also says something about the market, but still I wouldn't have predicted this two years ago).
If Win2k gets a higher rating than Linux, then why do we have stuff like this [cert.org] happening?
Read the certification assumptions: cooperative users in a benign environment, and network connections only to hosts in the same administrative domain. In short: "Don't use this on the Internet, or the certification is completely meaningless."
Furthermore, certification just guarantees that a certain process is followed, and the process itself doesn't guarantee anything about implementation errors (except for the mitigation process), at least at such low levels as EAL4+.
(AFAIK, it wasn't even the default configuration that was certified.)
"We want to make engaging with communities easier and friendlier with this interface. The tools [to access Usenet] have not evolved while there is so much to go after," Smith said.
Of course the tool doesn't evolve if you don't invest work in it. In the past, Microsoft simply refused to fix a few annoying bugs in their newsreader implementations which significantly degraded their user experience.
Now that DNA fingerprinting is in wide use, first collisions are reported.
Let's hope that more of such cases with completely credible alibis appear before someone is convicted based on the supposedly unrefutable scientific evidence of a DNA fingerprint.
IPv6 is bad because Cisco routers suck. No, wait, "Many of Cisco's routers" suck. You can' be serious! Once IPv6 gets off the ground, IPv6 will become fast path and eventually IPv4 will be dropped to legacy mode.
On most Cisco high-end routers, upgrading to larger IP addresses requires soldering (or replacement of fundamental router components, which amounts to the same thing). At the moment, only one or two linecards for the GSR series support IPv6 routing at wire speed (and the multi-purpose CPUs on the others are far too slow to route anything of importance). The 65xx/76xx series requires hardware upgrades which are not yet available AFAIK (several TCAMs have a word width which is too small for IPv6).
IPv6 is ready for prime time.
Not at a global level. The current approach to global routing is so discouraging that many people plan to continue using NAT (and IPv4) to gain the routing flexibility they need.
All the major OSses support it.
Only with a very reduced feature set, and most currently deployed embedded systems don't support IPv6 at all. For example, IPsec for IPv4 is much more widely available than for IPv6.
Thanks. "Alternative emulation products" are also mentioned. Certainly some of the legacy applications can also run under Wine, and not only under Windows in VMWare emulation.
The suggested ACL settings break fast switching...so ACL is not the best solution for many.
I'm not sure what you are talking about. "Fast switching" is an obsolete Cisco marketing. Maybe this is an accident and you allude to the possibility that filters decrease forwarding performance. However, quite a lot Cisco routers support either wirespeed ACLs or specific ACLs for traffic directed at the router (which do not impact forwarding performance).
Yes, and some people do not apply ACLs to their core networks due to the fact that cores are supposed to be extremely fast. In this case, an update can be said to be needed.
Huh? It's cheaper to drop a packet at the process switching level than to actually forward it to the process that implements the corresponding service.
We are talking about packets targeted at the router, and filters for them are not necessarily in the forwarding path (they can be implemented there to protect the main CPU(s) from DDOS attacks, of course). For forwarded packets, you are correct that this is problematic on core routers, e.g. very few GSR linecards support more than a few dozen ACL entries per interface, some do not support any filters at all.
Importance of shaming those who published this exploit
Why? Most ISPs are very grateful to have something to test if their countermeasures are effective.
Do you really want to upgrade all your core routers at once, and take the risk of introducing a bug which brings down your whole network? It's often better to apply some workaround and schedule an incremental update. In this case, you really want to test if your workaround is effective.
If you haven't yet received notification from your NOC that they're going to be doing maintenance, you really need to impress upon them to get this fixed. In a nutshell, this flaw could allow a malicious hacker to shut down traffic to your servers.
First of all, your network might be running on non-Cisco gear (yes, there are other vendors).
Second, the fact that so many NOCs have to apply emergency patches is scaring. I can understand that NOCs hesitate to install the latest release just after it has been published (some of the releases which include the fix have been available for months), but this particular bug only affects you if your router is insufficiently protected by ACLs against all kinds of malicious traffic. You really want to install such ACLs to mitigate the effect of typical DoS attacks targeted at the router itself, and if you've done your homework, bugs like the present one do not require emergency maintainance.
Slashdot Mirror
By going after the end users they can create clarity in the courts because the end users probably won't put up a defence like IBM or RedHat would. They simply wouldn't be able to afford the legal bill.
And usually, these end users can sue their vendors in turn.
This creates a massive distributed attack on the vendors. In Germany, there was already a case remotely like this (it involved trademark infringement), and a court ruled that it going after end users to create preasure on a specific vendor is illegal.
DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism, whereby a cartel of ~5 companies with keys that got into the original Netscape release essentially rule the roost, because Joe Average has no idea how to install a new root key in his browser. The cheapest key of this type will cost you ~$150 per year, and you can't use it to make more keys.
A browser key costs $250,000 per year, and $250,000 up front for audits etc., AFAIK.
No. Many of us realized that it is august and bloody hot, and an outage was likely.
You have regular power outages?
And you still worry about this terrorism crap?
Anyone still asking where you really have to search if you want to find WMD? Small hint: not in the middle east...
Israel probably has some.
According to this article, the iBot costs $29,000. Most people who would benefit from this technology cannot afford it, unfortunately.
ftp as a protocol is far simpler to implement than ssh2 for example, so if you have no authentication to do, use ftp.
FTP is not really firewall-friendly. But if you want to run it, vsftpd is a good choice (certainly the best one I've looked at so far).
I think the problem here is liability. If a software glitch caused objects to vanish, or improvements to the game shifted the balance and (inadvertedly) change the value of items, people would suddenly lose real money, and might sue.
Depends on your distribution, I imagine:
This is exactly my point. Marcelo just doesn't care about security issues (look at the release cycles). You should run vendor kernels on production machines, not the kernel.org version (that's the public opinion of quite a few influential kernel developers!).
However, this solves only part of the problem. Since there is no central source of security-related information, we are fully hit by the Chinese Whisper phenomenon.
For example, Red Hat wrote in their advisory:
CAN-2003-0552: Jerry Kreuscher discovered that the Forwarding table could be spoofed by sending forged packets with bogus source addresses the same as the local host.
"Forwarding table" could mean that IP forwarding is affected, but Debian writes:
Linux 2.4.x allows remote attackers to spoof the bridge forwarding table via forged packets whose source addresses are the same as the target.
So who's right? Are you safe if you don't run bridging (and maybe just IP forwarding), or are you still vulnerable?
I guess we'll just have to disagree. I think that, in comparison, Linux advisories tend to be much better. The fixes are even better because i can tell before applying exactly what the impact will be, and whether or not the fix actually fixes the underlying problem or just a symptom.
Quote from a recent Debian advisory on phpgroupware:
- CAN-2003-0599: Unknown vulnerability in the Virtual File System
(VFS) capability for phpGroupWare 0.9.16preRC and versions before
0.9.14.004 with unknown implications, related to the VFS path being
under the web document root.
Quite helpful, eh?
The only reason we aren't completely lost is the availability of source code patches. However, how many shops which run Linux have employees with the skills and knowledge necessary to quickly analyze source code and recommend how to proceed?
Do you really think that Microsoft publishes security advisories for kernel problems that others don't point out and make public? The one you referenced was specifically referencing a third party which notified them. The Linux community also issues advisories for widely-known kernel issues as well.
Only true if you define "widely known" to mean "we issued an advisory".
I haven't seen a Windows kernel advisory, either.
Here us one.
Alan Cox won't reveal anything about kernel security out of fear of the DMCA.
He can use an anonymous remailer if he wants to publish verifiable information about security vulnerabilities. But Alan is neither the Linux Security Czar, nor does he maintain 2.4.x.
However, it's true that publishing detailed vendor security advisories results in significant legal risks for the vendor. For software, it appears to be easy to exclude any warranties, but not for documents describing its behavior. But guess what? Microsoft is now willing to take such risks to protect customers. Why shouldn't Red Hat do the same?
Most of the published insecurities with either system are in the libraries or applications, not the kernel.
This certainly doesn't exempt developers from handling security issues if they arise anyway. There are still enough security issues in the kernel, and the maintainers should have gained some experience in dealing with it.
But the kernel is just symptomatic for the whole system. Many subprojects aren't much better. Some do not bother to issue any advisories at all, some prefer very cryptic ones (BIND, Apache, OpenSSH). Sometimes, there are shining exceptions, such as recent Postfix advisory (however regrettable its necessity might be). Everything's there, especially how to tell if you are vulnerable, and how to apply countermeasures without changing the software itself. Compare it with the advisory from Red Hat.
With their new mentality, everyone will say, "so why should we bother with Microsoft when we can go a more open and cheaper route?"
Yes, this is another way things could turn out.
"Right now, their advisories are already among the best the market offers"
Hahahahahahahahahahahaha!!!!!!!!!!
Actually, this isn't funny. It certainy shows that something is wrong. But at the moment, Microsoft easily outperforms Red Hat, SuSE and all the commercial UNIX vendors. And have you ever seen a Linux advisory (i.e. for the kernel itself)? Only the Netfilter maintainers seem to release them for their subsystem.
Most linux/bsd distros default config are quite secure, whereas the default in Windows (which most people use) is extremely open and very vulnerable.
This is true at the moment, but it's changing with new product releases.
For example, on Windows Server 2003, IIS is not installed by default, and if you install it, it binds to localhost only by default. I find this rather impressive for Microsoft because it shows that the company sacrifices trivial installation for more security. I wonder where they are heading. IMHO, it's getting more and more likely that Microsoft crushes the free software competition in the security area. Not because of certification, but because of more reliable software, better product management, courage to make decisions which inconvenience users etc. Right now, their advisories are already among the best the market offers (which also says something about the market, but still I wouldn't have predicted this two years ago).
I would guess that IBM wanted to go for the faster, cheaper rating first and wait to get it certified higher.
Basically, they had no choice. I don't know about EAL3, but EAL4 requires features which are only implemented as exeperimental kernel patches.
(The official Linux versions are far beyond NT 3.1 as far as access control etc. is concerned.)
If Win2k gets a higher rating than Linux, then why do we have stuff like this [cert.org] happening?
Read the certification assumptions: cooperative users in a benign environment, and network connections only to hosts in the same administrative domain. In short: "Don't use this on the Internet, or the certification is completely meaningless."
Furthermore, certification just guarantees that a certain process is followed, and the process itself doesn't guarantee anything about implementation errors (except for the mitigation process), at least at such low levels as EAL4+.
(AFAIK, it wasn't even the default configuration that was certified.)
"We want to make engaging with communities easier and friendlier with this interface. The tools [to access Usenet] have not evolved while there is so much to go after," Smith said.
Of course the tool doesn't evolve if you don't invest work in it. In the past, Microsoft simply refused to fix a few annoying bugs in their newsreader implementations which significantly degraded their user experience.
Now that DNA fingerprinting is in wide use, first collisions are reported.
Let's hope that more of such cases with completely credible alibis appear before someone is convicted based on the supposedly unrefutable scientific evidence of a DNA fingerprint.
IPv6 is bad because Cisco routers suck. No, wait, "Many of Cisco's routers" suck. You can' be serious! Once IPv6 gets off the ground, IPv6 will become fast path and eventually IPv4 will be dropped to legacy mode.
On most Cisco high-end routers, upgrading to larger IP addresses requires soldering (or replacement of fundamental router components, which amounts to the same thing). At the moment, only one or two linecards for the GSR series support IPv6 routing at wire speed (and the multi-purpose CPUs on the others are far too slow to route anything of importance). The 65xx/76xx series requires hardware upgrades which are not yet available AFAIK (several TCAMs have a word width which is too small for IPv6).
IPv6 is ready for prime time.
Not at a global level. The current approach to global routing is so discouraging that many people plan to continue using NAT (and IPv4) to gain the routing flexibility they need.
All the major OSses support it.
Only with a very reduced feature set, and most currently deployed embedded systems don't support IPv6 at all. For example, IPsec for IPv4 is much more widely available than for IPv6.
Thanks. "Alternative emulation products" are also mentioned. Certainly some of the legacy applications can also run under Wine, and not only under Windows in VMWare emulation.
No, fast switching is alive and well:
In this case, you should pick your examples more carefully, and avoid pointing to products which are officially end-of-life. 8-)
Ingress filtering on a Cisco via ACLs is only effective on the 75xx class routers.
On other Cisco IOS products, the input queue processing preceeds the ACL processing, so these devices can be DoS'd no matter what ACLs are in place.
You should contact Cisco PSIRT and tell them to correct their adviory if this is really the case.
The suggested ACL settings break fast switching...so ACL is not the best solution for many.
I'm not sure what you are talking about. "Fast switching" is an obsolete Cisco marketing. Maybe this is an accident and you allude to the possibility that filters decrease forwarding performance. However, quite a lot Cisco routers support either wirespeed ACLs or specific ACLs for traffic directed at the router (which do not impact forwarding performance).
Yes, and some people do not apply ACLs to their core networks due to the fact that cores are supposed to be extremely fast. In this case, an update can be said to be needed.
Huh? It's cheaper to drop a packet at the process switching level than to actually forward it to the process that implements the corresponding service.
We are talking about packets targeted at the router, and filters for them are not necessarily in the forwarding path (they can be implemented there to protect the main CPU(s) from DDOS attacks, of course). For forwarded packets, you are correct that this is problematic on core routers, e.g. very few GSR linecards support more than a few dozen ACL entries per interface, some do not support any filters at all.
I doubt that these passwords are very strong.
For example, for even-numbered positions in the password, the letters "s" and maybe "g" will be quite common.
Importance of shaming those who published this exploit
Why? Most ISPs are very grateful to have something to test if their countermeasures are effective.
Do you really want to upgrade all your core routers at once, and take the risk of introducing a bug which brings down your whole network? It's often better to apply some workaround and schedule an incremental update. In this case, you really want to test if your workaround is effective.
If you haven't yet received notification from your NOC that they're going to be doing maintenance, you really need to impress upon them to get this fixed. In a nutshell, this flaw could allow a malicious hacker to shut down traffic to your servers.
First of all, your network might be running on non-Cisco gear (yes, there are other vendors).
Second, the fact that so many NOCs have to apply emergency patches is scaring. I can understand that NOCs hesitate to install the latest release just after it has been published (some of the releases which include the fix have been available for months), but this particular bug only affects you if your router is insufficiently protected by ACLs against all kinds of malicious traffic. You really want to install such ACLs to mitigate the effect of typical DoS attacks targeted at the router itself, and if you've done your homework, bugs like the present one do not require emergency maintainance.