How should 'major', though? When most Firefox-borked sites were coded, Firefox probably had less than 5% (around what Safari had, last I heard). Is 5% enough to overlook? What about 3%? 1%?
If you code to the standard, at least you can blame browsers for their broken implementation.
innerHTML is nonstandard, but supported in most modern browsers, so I often do it anyway. Ah, the mentality that makes so many web pages crap out in Firefox or Opera...
Code to the standard and let your client decide what obscure browser to use.
C isn't really suited for text manipulation. It's unlikely that you'd need the raw power C gives for such a small task (unless you're running on really old computers). You could get away with Perl--this is basically what it was designed for.
Assuming the more common (though less precise) definition of NAT (translating from routable IP address space to non-routable IP address space), NAT protects people from incoming connections.
While DHCP might make such things easier, it also makes it easier to configure things in the first place. Users have a hard time with static IP. They have an easy time with "plug it in and it works."
If DHCP hadn't been invented to solve the IPv4 shortage, it would have been invented to keep helpdesk calls to a minimum. Actually, this seems to be an 'ease of use' that was ignored when this sub-thread about ease-of-use was started. Computer network configuration has come a long way in 20 years, at the expense of service configuration.
I'm aware that NAT != firewall, and I'm aware that IPV6 can be firewalled. What I'm not aware of is why your average home user would buy a firewall in the first place if it didn't also happen to allow them to share their connection. Most users aren't concerned with security (evidenced by the utter mess that is the Internet right now) so that can't be it.
In fact, it's even easier. Instead of "Allow this traffic to/from this device, and OBTW, you need to also define a special NAT rule", you get just the first part. If you don't know how to do that, but can read directions provided with your firewall appliance, it's easy. If you don't know how to do that, and you don't know that you don't know how to do that (i.e. you run the software and it just fails) then you're kinda stuck. That's how most people are with computers. They know that they want to let someone else see their webcam, but they don't know why they get "connection refused", and they don't know where to look to find out why they get that error.
Hello? Switches? Switches extend layer-2 so that you can effectively have multiple devices on the same wire. In the case of an ISP, each device would query the ISP DHCP server to get its REAL IP. NAT is not required unless your ISP artificially limits the number of IP addresses your modem is allowed to pull. Most ISPs do this for several reasons, not the least of which is that they have a limited number of addresses available (a problem which IPV6 solves).
About 8 years ago, I was in this very position. We had a commercial account using cable modems because the cost/bandwidth was great. With a commercial account, we were allocated 5 IP addresses, and since we weren't using wireless at the time, we didn't bother with NAT. Just had a dumb Linksys switch connected to the CM and 3 computers connected to the switch, each with their own public IP address.
Not much smarter, really, assuming that the IPV6 block allocations are public knowledge. All the worm has to do is get a list of IPV6 allocations and scan those networks. The worm doesn't even have to do this itself--most worms talk to botnet controllers, which could host the updated network information harvested by a human.
Don't knock worm developers--they're pretty bright. We're already seeing worms that exhibit p2p-like behavior (the entire botnet is decentralized), use encryption to avoid IDS, and run over UDP (which passed in the default firewall policy for many firewalls).
20 years ago, though, the people who were doing this sort of thing knew at least a LITTLE something about computers and networks. Now that it's got mass adoption, of course people don't know how to do things. That's really a big part of the reason that malware propagates so easily in the first place.
Even so, there have been attempts to address it using uPNP. And uPNP is a security hazard, much like running without a firewall. Shocking, eh?:)
Routing is an issue. We'll run out of allocatable blocks long before we actually run out of IPs, even if the big, unused/8 blocks get broken up. It's kinda like the FAT file system--lots of really small files will completely eat up the disk space because they get allocated large clusters and they can't share.
IPV6 handles routing almost automagically. We should see fewer problems with chunking and "wasted" IP addresses. And of course, there are many other benefits. I honestly can't wait for the day when IPV4 is a terrible memory.
We'd probably be in worse straits if we weren't using NAT for connection sharing. Imagine if IPV6 was the norm and everyone got something like a/26 to their home instead of a/32. There would be no NAT boxes required to share your connection amongst several computers, meaning all those worms would have affected just about every Windows computer on the Internet (instead of just the ones that were directly connected).
NAT really does turn out to be a good thing overall for most home users. They are forced to use it if they want multiple computers on the Net (in most cases), and it protects them.
Of course, college tuition keeps rising, which means that it takes more time/money to profit from the education. Of course graduates want more money to make up that cost!
America is really in a downward spiral of inflation. We had a great economy many years ago based primarily on sheer raw materials. Now, tiny electronic parts are the new 'raw materials', and we get them all from Asia. They're put together and sold in America (you think the people working for $0.30/hr in sweatshops can afford them? Who do you think supports the companies that make all the flashy goods you referred to? Overpaid Americans!)
We're probably less than a century away from seeing one world currency and all artificial trade barriers (primarily national lines) dissolved. At that point, there will be an economy truly based upon value for the work you do--and if someone in another country does the work better on average, that country will start to prosper more than the US.
I have to use WEP because my Nintendo DS cannot do WPA. I've never managed to get my DS to connect to my access point, whether it's WEP, open, or what.
I don't have a Windows machine, so the USB dongle won't help, either. Kinda sucks for games where unlockable content exists, but you have to connect to the Wifi to get it.
It may not add security, but it prevents Windows from trying to connect to it (as does using WEP, even though WEP is trivial to crack), so it can be useful.
From the freaking summary, man:
Because of that limitation, the only freely available mail client it supports is Windows Live Desktop, which is only available on Windows and I'm worried its ads might be vulnerable to malware just like the ones in Live Messenger. I depend on my mail client and I am concerned about this, because we're not allowed to forward our mail but are responsible for information received there from the University and classes, I'm not on a Windows machine, and I don't have the time to regularly check for web-mail, during the day." He notes the client, notes that it is Windows only.
I touched on "why not just do it" in another reply.
With timing attacks, not only do you have to get the shell code right, you also have to get the timing right, and that's mostly going to be luck unless you have control over a lot of factors.
With a wifi timing attack, you need even more control over your environment, because stray interference can cause you to lose the opportunity to exploit and simply cause a crash.
You really have to piece together a lot of this puzzle to understand some of the underlying issues.
Timing is everything with wireless. An overflow which causes a crash one time may allow for remote code execution the next. It's all very tricky to get right, and there are non-driver issues that can cause problems (things like interference, which you can't control). Maynor or Cache alluded to this at one point, and it was speculated that this might have been the real reason that they did a video demo instead of a live one--a live exploit demo which fails (but crashes the system) 6 times before it succeeds isn't all that impressive.
So there were very similar (nearly identical) bugs in other vendor's drivers. FreeBSD had patched their version of the bug in January 2006. It was a similar exploit in a similar driver for similar hardware. It's far from a stretch to assume that he noticed his Macbook crash when he got it (he claims he was fuzzing other devices at the time here: http://erratasec.blogspot.com/2007/03/apple-infoan d-thats-all-folks.html ), he started investigating the chipset, found that it was Atheros, started researching the bug, and discovered the near identical one that had been patched 6 months ago. For someone with the knowledge, it should be trivial to adapt to the new platform, given the similarities between the FreeBSD and Apple drivers.
Now it all gets pretty fuzzy around the time that they claim to be using 3rd party hardware. Why do that? Why does the video clearly show the Apple interface with an Apple MAC if they were using a 3rd party card?
If we assume that he's lying, the video shows all of this because it was rigged. If we assume that he's telling the truth, then that is just more evidence to the "Apple coverup".
The point of all of this, though, is that I think there's a certain amount of plausibility to all of this. I don't think that the situation I outlined above is a stretch. I do think that if it even remotely resembles the reality of the situation, then Maynor and Cache were exaggerating their own skills in determining the exploit. There was a pretty big inference by everyone at Blackhat that Maynor and Cache had discovered and engineered the exploit alone, not that it was based upon a pre-existing exploit for another OS. If they didn't intentionally imply that...well, then it sucks to be them, but their credibility takes a bit of a hit for it.
Oh, and the timing issue I mentioned above? Could well be why he only demoed a crash instead of a full exploit this time. He's got Apple's word that remote code execution is possible, and he's shown that he can cause the crash. Who knows how many takes their video took to get right? With a live demo, you really only get one shot.
I was at that Black Hat talk in Vegas. They didn't do the demo--they showed a video of it. They did it this way PRECISELY because there were sniffers in the audience.
Why can't you merge changes back to BSD-licensed code? A BSD-licensed driver which makes it into the kernel is probably going to stay BSD-licensed, isn't it? Wouldn't that mean that changes to that driver could remain BSD?
If someone's been taking BSD-licensed code and changing the license to GPL when it goes into the kernel tree, that's kinda lousy, in my opinion.
Maybe. What exactly protects the key? Certainly not copyright or trademark. Trade secret? Those are fair game for reverse engineering.
A competent judge who was made to understand the difference between a decryption program, a key, and a decryption program with the key would have to rule that spreading the key itself does not violate the DMCA, or that the decryption program is just an implementation of an algorithm, and not an circumvention tool unless combined with the key.
I don't think they can have it both ways. If distributing the program is illegal, then distributing the keys must not be (after all, the key is not a program which can decrypt the copyrighted video). This should actually make things easier, since the keys are the hard part to find (any idiot can implement an algorithm that's an open specification).
Slashdot Mirror
How should 'major', though? When most Firefox-borked sites were coded, Firefox probably had less than 5% (around what Safari had, last I heard). Is 5% enough to overlook? What about 3%? 1%?
If you code to the standard, at least you can blame browsers for their broken implementation.
Code to the standard and let your client decide what obscure browser to use.
Indeed. We use many of the Networking-based libraries in my office. They're quite useful.
C isn't really suited for text manipulation. It's unlikely that you'd need the raw power C gives for such a small task (unless you're running on really old computers). You could get away with Perl--this is basically what it was designed for.
Assuming the more common (though less precise) definition of NAT (translating from routable IP address space to non-routable IP address space), NAT protects people from incoming connections.
For the purposes of this exercise, yes.
While DHCP might make such things easier, it also makes it easier to configure things in the first place. Users have a hard time with static IP. They have an easy time with "plug it in and it works."
If DHCP hadn't been invented to solve the IPv4 shortage, it would have been invented to keep helpdesk calls to a minimum. Actually, this seems to be an 'ease of use' that was ignored when this sub-thread about ease-of-use was started. Computer network configuration has come a long way in 20 years, at the expense of service configuration.
I'm aware that NAT != firewall, and I'm aware that IPV6 can be firewalled. What I'm not aware of is why your average home user would buy a firewall in the first place if it didn't also happen to allow them to share their connection. Most users aren't concerned with security (evidenced by the utter mess that is the Internet right now) so that can't be it. In fact, it's even easier. Instead of "Allow this traffic to/from this device, and OBTW, you need to also define a special NAT rule", you get just the first part. If you don't know how to do that, but can read directions provided with your firewall appliance, it's easy. If you don't know how to do that, and you don't know that you don't know how to do that (i.e. you run the software and it just fails) then you're kinda stuck. That's how most people are with computers. They know that they want to let someone else see their webcam, but they don't know why they get "connection refused", and they don't know where to look to find out why they get that error.
Hello? Switches? Switches extend layer-2 so that you can effectively have multiple devices on the same wire. In the case of an ISP, each device would query the ISP DHCP server to get its REAL IP. NAT is not required unless your ISP artificially limits the number of IP addresses your modem is allowed to pull. Most ISPs do this for several reasons, not the least of which is that they have a limited number of addresses available (a problem which IPV6 solves).
About 8 years ago, I was in this very position. We had a commercial account using cable modems because the cost/bandwidth was great. With a commercial account, we were allocated 5 IP addresses, and since we weren't using wireless at the time, we didn't bother with NAT. Just had a dumb Linksys switch connected to the CM and 3 computers connected to the switch, each with their own public IP address.
Not much smarter, really, assuming that the IPV6 block allocations are public knowledge. All the worm has to do is get a list of IPV6 allocations and scan those networks. The worm doesn't even have to do this itself--most worms talk to botnet controllers, which could host the updated network information harvested by a human.
Don't knock worm developers--they're pretty bright. We're already seeing worms that exhibit p2p-like behavior (the entire botnet is decentralized), use encryption to avoid IDS, and run over UDP (which passed in the default firewall policy for many firewalls).
It's clearly still available.
:)
20 years ago, though, the people who were doing this sort of thing knew at least a LITTLE something about computers and networks. Now that it's got mass adoption, of course people don't know how to do things. That's really a big part of the reason that malware propagates so easily in the first place.
Even so, there have been attempts to address it using uPNP. And uPNP is a security hazard, much like running without a firewall. Shocking, eh?
Routing is an issue. We'll run out of allocatable blocks long before we actually run out of IPs, even if the big, unused /8 blocks get broken up. It's kinda like the FAT file system--lots of really small files will completely eat up the disk space because they get allocated large clusters and they can't share.
IPV6 handles routing almost automagically. We should see fewer problems with chunking and "wasted" IP addresses. And of course, there are many other benefits. I honestly can't wait for the day when IPV4 is a terrible memory.
We'd probably be in worse straits if we weren't using NAT for connection sharing. Imagine if IPV6 was the norm and everyone got something like a /26 to their home instead of a /32. There would be no NAT boxes required to share your connection amongst several computers, meaning all those worms would have affected just about every Windows computer on the Internet (instead of just the ones that were directly connected).
NAT really does turn out to be a good thing overall for most home users. They are forced to use it if they want multiple computers on the Net (in most cases), and it protects them.
Of course, college tuition keeps rising, which means that it takes more time/money to profit from the education. Of course graduates want more money to make up that cost!
America is really in a downward spiral of inflation. We had a great economy many years ago based primarily on sheer raw materials. Now, tiny electronic parts are the new 'raw materials', and we get them all from Asia. They're put together and sold in America (you think the people working for $0.30/hr in sweatshops can afford them? Who do you think supports the companies that make all the flashy goods you referred to? Overpaid Americans!)
We're probably less than a century away from seeing one world currency and all artificial trade barriers (primarily national lines) dissolved. At that point, there will be an economy truly based upon value for the work you do--and if someone in another country does the work better on average, that country will start to prosper more than the US.
I don't have a Windows machine, so the USB dongle won't help, either. Kinda sucks for games where unlockable content exists, but you have to connect to the Wifi to get it.
It may not add security, but it prevents Windows from trying to connect to it (as does using WEP, even though WEP is trivial to crack), so it can be useful.
BartPE is pretty useful: it's a Windows LiveCD environment.
http://www.nu2.nu/pebuilder/
I touched on "why not just do it" in another reply.
With timing attacks, not only do you have to get the shell code right, you also have to get the timing right, and that's mostly going to be luck unless you have control over a lot of factors.
With a wifi timing attack, you need even more control over your environment, because stray interference can cause you to lose the opportunity to exploit and simply cause a crash.
You really have to piece together a lot of this puzzle to understand some of the underlying issues.
n d-thats-all-folks.html ), he started investigating the chipset, found that it was Atheros, started researching the bug, and discovered the near identical one that had been patched 6 months ago. For someone with the knowledge, it should be trivial to adapt to the new platform, given the similarities between the FreeBSD and Apple drivers.
Timing is everything with wireless. An overflow which causes a crash one time may allow for remote code execution the next. It's all very tricky to get right, and there are non-driver issues that can cause problems (things like interference, which you can't control). Maynor or Cache alluded to this at one point, and it was speculated that this might have been the real reason that they did a video demo instead of a live one--a live exploit demo which fails (but crashes the system) 6 times before it succeeds isn't all that impressive.
So there were very similar (nearly identical) bugs in other vendor's drivers. FreeBSD had patched their version of the bug in January 2006. It was a similar exploit in a similar driver for similar hardware. It's far from a stretch to assume that he noticed his Macbook crash when he got it (he claims he was fuzzing other devices at the time here: http://erratasec.blogspot.com/2007/03/apple-infoa
Now it all gets pretty fuzzy around the time that they claim to be using 3rd party hardware. Why do that? Why does the video clearly show the Apple interface with an Apple MAC if they were using a 3rd party card?
If we assume that he's lying, the video shows all of this because it was rigged. If we assume that he's telling the truth, then that is just more evidence to the "Apple coverup".
The point of all of this, though, is that I think there's a certain amount of plausibility to all of this. I don't think that the situation I outlined above is a stretch. I do think that if it even remotely resembles the reality of the situation, then Maynor and Cache were exaggerating their own skills in determining the exploit. There was a pretty big inference by everyone at Blackhat that Maynor and Cache had discovered and engineered the exploit alone, not that it was based upon a pre-existing exploit for another OS. If they didn't intentionally imply that...well, then it sucks to be them, but their credibility takes a bit of a hit for it.
Oh, and the timing issue I mentioned above? Could well be why he only demoed a crash instead of a full exploit this time. He's got Apple's word that remote code execution is possible, and he's shown that he can cause the crash. Who knows how many takes their video took to get right? With a live demo, you really only get one shot.
I was at that Black Hat talk in Vegas. They didn't do the demo--they showed a video of it. They did it this way PRECISELY because there were sniffers in the audience.
A long, costly lawsuit is one more step towards the goal: getting rid of absurd activation schemes.
Why can't you merge changes back to BSD-licensed code? A BSD-licensed driver which makes it into the kernel is probably going to stay BSD-licensed, isn't it? Wouldn't that mean that changes to that driver could remain BSD?
If someone's been taking BSD-licensed code and changing the license to GPL when it goes into the kernel tree, that's kinda lousy, in my opinion.
Maybe. What exactly protects the key? Certainly not copyright or trademark. Trade secret? Those are fair game for reverse engineering.
A competent judge who was made to understand the difference between a decryption program, a key, and a decryption program with the key would have to rule that spreading the key itself does not violate the DMCA, or that the decryption program is just an implementation of an algorithm, and not an circumvention tool unless combined with the key.
I don't think they can have it both ways. If distributing the program is illegal, then distributing the keys must not be (after all, the key is not a program which can decrypt the copyrighted video). This should actually make things easier, since the keys are the hard part to find (any idiot can implement an algorithm that's an open specification).
They aren't preventing him from expressing himself. They are preventing him from expressing himself on their website and in their ads.