Index
Search and browse in Computer · Security
Errata SecurityErrata Security is a high-end cyber security consulting company.
I'm on the opposite side of the political spectrum from Byron Sonne, in that I believe in "globalization", the "G20", and all that he opposes. But even I recognize that the case against him was a travesty. There was never any good evidence against him. Instead, he was guilty of being different, as different as the rest of us in cybersecurity.
What defines us is that we are interested in "security". For example, I was detained by TSA for taking pictures of their security. It's an act that is explicitly allowed by TSA guidelines, it poses no threat to airline safety, yet because it's unusual behavior, they detained me.
I was only detained for a couple hours, but had I been arrested and the FBI had grabbed all my emails, search history, and hard drives, they could probably build a case that I was plotting something evil. That's because there is a lot of strange stuff that can't be explained except by assuming that it's all part of my bigger master plan. For example, I bought some Teflon online for $50 to coat the surface of my desk because I was curious what that would feel like with the mouse, because I'm a geek, and that's the sort of thing geeks do. I can't imagine how Teflon could be used for Evil, but I'm sure whatever explanation the FBI comes up with will seem more plausible than the truth. (BTW, Teflon is not nearly as frictionless as I'd hoped).
In Sonne's case, they found "explosive" material. Is that because he's a terrorist planning to blow things up? Or is it because he's a rocketry enthusiast? Well, when you are police, the first explanation looms a whole lot more probable than the second.
That makes all of us guilty. We all appear as a threat to security, and we all do strange things that are most easily explained by whatever theory the police concoct. Which means that all of us can go through what Byron Sonne went through, divorce, losing his job, and losing his life's savings -- even when found innocent -- for the crime of simply being a bit odd.
Update: @SergeyBratus tweets "What might 'they' think if I do/say this" is the most powerful form of control".
What defines us is that we are interested in "security". For example, I was detained by TSA for taking pictures of their security. It's an act that is explicitly allowed by TSA guidelines, it poses no threat to airline safety, yet because it's unusual behavior, they detained me.
I was only detained for a couple hours, but had I been arrested and the FBI had grabbed all my emails, search history, and hard drives, they could probably build a case that I was plotting something evil. That's because there is a lot of strange stuff that can't be explained except by assuming that it's all part of my bigger master plan. For example, I bought some Teflon online for $50 to coat the surface of my desk because I was curious what that would feel like with the mouse, because I'm a geek, and that's the sort of thing geeks do. I can't imagine how Teflon could be used for Evil, but I'm sure whatever explanation the FBI comes up with will seem more plausible than the truth. (BTW, Teflon is not nearly as frictionless as I'd hoped).
In Sonne's case, they found "explosive" material. Is that because he's a terrorist planning to blow things up? Or is it because he's a rocketry enthusiast? Well, when you are police, the first explanation looms a whole lot more probable than the second.
That makes all of us guilty. We all appear as a threat to security, and we all do strange things that are most easily explained by whatever theory the police concoct. Which means that all of us can go through what Byron Sonne went through, divorce, losing his job, and losing his life's savings -- even when found innocent -- for the crime of simply being a bit odd.
Update: @SergeyBratus tweets "What might 'they' think if I do/say this" is the most powerful form of control".
The government has recently put out a scary advisory claiming hackers are targeting travelers with malicious popups on the hotel networks. Cybersec people travel a lot, so they can confirm this by checking their own hotel.
The easiest way is by doing a "view source" on an HTTP (not HTTPS) web page and see if anything has been added. There are two ways hackers might change things. The first is that they might replace the page completely with a framing page, and then stick the real page inside the frame. The second is that they simply append some JavaScript code at the end, either right before or right after the page.
Go to some some famous login page, like http://twitter.com (you have to turn off things like HTTPSEverywhere for this to work). Don't login, just look at the raw page with "view source". Hit Ctrl-Ato select the entire thing, then Ctrl-C to copy, then paste it into an email and send it to me (pcap@erratasec.com). You can also check it yourself for suspicious framing or trailing JavaScript at the end.
Better yet, start "windump" or "tcpdump" on your machine, save to file, and email me the file, after capturing the login page (but before you login).
What can the hackers have broken into in order to man-in-the-middle webpages?
1. They have an evil WiFi access-point you connected to instead of the hotel's.
2. They compromised the hotel's access-point and installed OpenWRT on it.
3. They compromised a deep-packet-inspect device inside the hotel's network
4. They compromised a device in the upstream network.
If you send me raw captures, I should be able to figure this out, especially if during the capture you do a traceroute.
I've setup an email address to receive this information: pcap@erratasec.com.
The easiest way is by doing a "view source" on an HTTP (not HTTPS) web page and see if anything has been added. There are two ways hackers might change things. The first is that they might replace the page completely with a framing page, and then stick the real page inside the frame. The second is that they simply append some JavaScript code at the end, either right before or right after the page.
Go to some some famous login page, like http://twitter.com (you have to turn off things like HTTPSEverywhere for this to work). Don't login, just look at the raw page with "view source". Hit Ctrl-A
Better yet, start "windump" or "tcpdump" on your machine, save to file, and email me the file, after capturing the login page (but before you login).
What can the hackers have broken into in order to man-in-the-middle webpages?
1. They have an evil WiFi access-point you connected to instead of the hotel's.
2. They compromised the hotel's access-point and installed OpenWRT on it.
3. They compromised a deep-packet-inspect device inside the hotel's network
4. They compromised a device in the upstream network.
If you send me raw captures, I should be able to figure this out, especially if during the capture you do a traceroute.
I've setup an email address to receive this information: pcap@erratasec.com.
According to this warning from the government, travelers are catching viruses from their hotel wifi. Should you be afraid?
No. Popups tricking you are a danger all the time, and all hotspots (whether at the hotel, or Starbucks, or the local bar) are always an increased danger. But they cite no evidence that hotels in particular are more dangerous.
That hotels are more dangerous is plausible. For example, some people have reported credible evidence of a hotel intercept browsing to give you more advertising, and some advertising networks are poor at filtering out malicious attacks. Combining these two, there may be a slightly higher incidence of infection at hotels. But only slightly, it's absurd thinking that hotels are a dramatically different threat, or that there's something special you should do to protect yourself at hotels that you wouldn't do everywhere.
The above advisory is especially deficient in it's recommendations of what you should do to protect yourself. People assume government agencies are more credible and more competent, but this advisory shows the reverse is true. The lack of evidence and bogus remedies demonstrate their incompetence.
It doesn't have to be the legitimate routers that do this (as it was in the Marriot or Tunisia cases). Instead, a hacker can create a hostile access-point, either an "evil twin" that pretends to be the same access-point right next to it (like one also named "Marriot Courtyard"), or simply an evil one with an independent name "Free WiFi".
This sort of evil access-point simply forwards traffic to the normal access-point, but changes things as described above. Hackers can buy $40 wall-wart access-points, re-flash them with a linux distro, and leave them behind in hotel rooms, coffee shops, airports, and so on. They'll likely earn more than $40 from hacking or advertising, so they don't mind the fact that eventually they'll get stolen.
No. Popups tricking you are a danger all the time, and all hotspots (whether at the hotel, or Starbucks, or the local bar) are always an increased danger. But they cite no evidence that hotels in particular are more dangerous.
That hotels are more dangerous is plausible. For example, some people have reported credible evidence of a hotel intercept browsing to give you more advertising, and some advertising networks are poor at filtering out malicious attacks. Combining these two, there may be a slightly higher incidence of infection at hotels. But only slightly, it's absurd thinking that hotels are a dramatically different threat, or that there's something special you should do to protect yourself at hotels that you wouldn't do everywhere.
The above advisory is especially deficient in it's recommendations of what you should do to protect yourself. People assume government agencies are more credible and more competent, but this advisory shows the reverse is true. The lack of evidence and bogus remedies demonstrate their incompetence.
Technical Details
The technical details are this: devices can change web pages as they pass through the device. The most common change is to append JavaScript to the end of a web-page (any web page) that does something interesting. That could be simply to do extra advertising, which was recently caught at a Marriot Hotel. Or, it could append code to steal passwords entered in the page, which repressive regimes like Tunisia were caught doing to their citizens. Or, it could popup a window telling somebody to download software.It doesn't have to be the legitimate routers that do this (as it was in the Marriot or Tunisia cases). Instead, a hacker can create a hostile access-point, either an "evil twin" that pretends to be the same access-point right next to it (like one also named "Marriot Courtyard"), or simply an evil one with an independent name "Free WiFi".
Back in 2005 I briefed some high-level military people about the danger of flash memory, how a worm infected computers can easily trash the boot flash, turning computers into bricks. Such a threat isn't targeted at desktops, but servers, routers, and SCADA control systems. In most of these systems, flash memory is soldered onto the motherboard, and but even those where it's not, replacing the flash isn't an easy process. The consequence is this: a mass attack against Cisco routers would take down large parts of the Internet for days, if not weeks. Such an attack against SCADA control systems in the power grid would cause a blackout that couldn't be fixed for weeks. On the other hand, the solution is straightforward: make the flash boot for these systems user-replaceable, and supply and extra two boot flashes with any system where failure of the flash is catastrophic. (You need two, because after the first attack, you are going to replace it and get pwned again, requiring a third for replacement after you've fixed what's going on). Also, change systems so that they require manual intervention before they can be updated. Unfortunately, most people will set the jumper once to "enable flash update" and never change it, so you need to make it a button that after you press it, will allow flash update only on the next reboot, but not after that until you press the button again. Apparently, the military is now using this scenario as a scare tactic as part of their power grab for more control of the Internet, as reported by NPR. Seriously, where did these people go to journalism school? Gen. Alexander and Mike McConnell have been exaggerating cybersecurity risks for several years now, and the press is eating it up without questioning their facts or their motivations, or talking to experts (I'm only one of many, judging from Twitter reactions) that believe otherwise. The NPR story totally distorts the risk. This isn't an "incident", hackers havne't done this yet, it's just something they could do in theory. This isn't a "vulnerability" that lets hackers break into computers, it's a risk of what might happen after hackers get through numerous defenses in order to reach those systems. There is no imminent threat here. Rather, it's an issue of long-term planning: when designing critical systems, assume that hackers can make computers not boot. This does not "underscore the need for public/private partnerships" or "information sharing" as NPR implies. Quite the opposite, the lies and distortions by Gen. Alexander indicate that the government cannot be trusted, and is probably a greater threat than hackers. No server farm has been lost to hackers destroying the boot flash, several have been lost from the FBI confiscating the haystack in search of needle. Why oh why doesn't the media have a left-wing bias? I'd've thought after the threat inflation that led to the Iraq War they would be more sensitive to such things.
In networking, a hardware "bypass" is a device that is inert when powered off, connecting copper wires or fiber optics straight through. But, when powered on, it flips relays, and redirects network traffic through an intermedia device, such as an IPS, load balancer, web accelerator, or web-app-firewall. If these devices fail, relays switch back, and traffic continues to flow as normal. You don't use these things for traditional firewalls, because you want things to "fail safe", to stop all traffic in case of failure, but you use these for pretty much every other inline device. The first bypass I know of was created by me back in 1998 for BlackICE Guard (the first IPS). This was back in the days with 100-mbps copper, when such devices could be built with simple relay switches. If I remember correctly, our first unit was an external device powered by the keyboard connection, and we used the serial port to communicate with it (level triggering with one of the RS-232 control pins). One startup, we first put the Ethernet adapters into forwarding mode, then sent a signal to flip the relays and insert ourselves into the traffic. We'd then ping the device on a regular basis to keep the relays open, so that if our software crashed, within a quart second, the relays would switch back again, allowing traffic to flow normally. The solution couldn't work for gigabit Ethernet, so we worked with a contract manufacturer to build one for us into the Ethernet card itself, who then immediately marketed it to other clients. None of our early IPS competitors had bypass, they assumed customers wanted an IPS to "fail safe" like a firewall, and was a major selling point for us. Now all IPSs have bypasses. We had to invent our own because we could find no existing solution, but these days, such things are quite common. There is a wikipedia page on it, and such cards readily available everywhere, such as from NewEgg.com. So my question is this: were we really the first? or does somebody know of an Ethernet bypass adapter that predates 1998? Also, does anybody have a picture of the first BlackICE bypass unit?
15 years ago, when we started the industry of white-hat hackers finding vulns and reporting them, "everyone knew" that open-source was more secure than closed-source because of the "many eyeballs" theory that the many people looking at open-source would find/fix bugs faster than in closed-source products. This was analogous to cryptography, where the only trustworthy crypto algorithms were those widely published and analyzed, and that anybody attempting "security through obscurity" by hiding their crypto algorithm was inevitably found to have made a serious mistake. But things never worked out this way. Open-source has failed to demonstrate any advantage in security. The problem is that while many eyeballs can look at open-source, they don't. Open-source programmers just don't have the incentive. They want to write new code and add new cool features, not try to break old stuff. Conversely, at Microsoft, many eyeballs do look at code. Microsoft pays them to, then pays other programers to attack the code with fuzzers and static analyzers. PHP may be more popular than Microsoft's ASP/.NET, but more eyeballs have looked at the Microsoft stuff. The recent "cgi-php" vuln is definite proof that the "many eyeballs" theory doesn't work. PHP is one of the most popular bits of code on the web. The vuln was obvious to any eyeballs looking at the code. Yet it sat there undiscovered for 7 years. I'm not saying Microsoft is any better, or that other factors don't exist that make open-source better than closed-source. I'm just saying that the "many eyeballs" theory has been proven false as much as any theory can be proven false. Things slip through the open-source development process that even a small number of "eyeballs" should've caught. The putative eyeballs haven't materialized. The days of open-source ideology is over, it's time we judged software on its individual merits, not its origin.
Update: On Twitter, Weev points out bug bounties. I think those are a winner. You can trust Google Chrome or Mozilla Firefox because they pay people to find bugs. This directs eyeballs their way. I trust Chrome over Internet Explorer not because it's open-source, but because they pay people to put eyeballs on it. Thus, the new axis is "bounties vs. no-bounties", not "open-source vs. close-source". Update: On Twitter, people are pointing out that we ought to "crowd-source" bug-bounties. Is "crowd-sourced" the new "open-source"? Update:On Twitter, Dan Kaminsky argues that it's not coder eyeballs that makes code secure, but user eyeballs.
#1#2#3#4#5#6
Update: On Twitter, Weev points out bug bounties. I think those are a winner. You can trust Google Chrome or Mozilla Firefox because they pay people to find bugs. This directs eyeballs their way. I trust Chrome over Internet Explorer not because it's open-source, but because they pay people to put eyeballs on it. Thus, the new axis is "bounties vs. no-bounties", not "open-source vs. close-source". Update: On Twitter, people are pointing out that we ought to "crowd-source" bug-bounties. Is "crowd-sourced" the new "open-source"? Update:On Twitter, Dan Kaminsky argues that it's not coder eyeballs that makes code secure, but user eyeballs.
#1#2#3#4#5#6
Google’s WiFi scandal is a good test of Internet activism. Are activists intellectuals with a special insight into the consequences of technology? Or are they more like dogs that chase every passing car? The implication is that Google was able to capture your personal information as they drove by in their StreetView cars. In fact, the data they collected is too fragmentary to be useful. Most WiFi is encrypted (and hence, not eavesdroppable), and even if unencrypted, chances are that StreetView collected nothing in the few seconds it took to drive by. In other words, Google had as much chance of capturing your password/email as they did of taking a picture at the precise moment you stepped out of your shower with the curtains open. Sure, such events happened a few thousand times, but this was tiny compared to the billions of homes StreetView drove past worldwide. This is the test for Internet privacy activists. They aren’t intellectuals. They don’t understand the technology of WiFi sniffing. They don’t understand that what Google collected is worthless. They assume the worst, about what Google was able to collect, and about Google’s intentions. It’s funny to watch. Google hasn’t been forthcoming with details about the WiFi overcollection because they recognize that there is a witch-hunt going on. Since any rational person should be able to recognize the overcollected data is worthless, any attack must therefore come from the lunatic fringe. But this convinces the fringe that there is an important cover-up. It’s like how the US keeps Area 51 secret (it’s a military base where they test stealth technology), which convinces the fringe that there is a UFO cover-up. You can verify this yourself. Download "BackTrack 5 r2", the well-known Linux destro with a bunch of hacking tools. Boot your laptop with BackTrack and run "Kismet", then drive around neighborhoods for a few hours. Then, back home, run the collected data through hacking tools like ‘dsniff’ or ‘ferret’ to see if you got anything useful. I consider myself an "activist", but I hate being lumped in with the fringe. The road to tyranny is paved with good intentions of ignorant activists. We should not have laws preventing StreetView from taking pictures of naked people in their bedrooms, we should instead expect people to close their curtains. We should not have laws preventing StreetView from collecting unencrypted data, we should expect people to encrypt. Freedom means personal responsibility, getting rid of personal responsibility gets rid of freedom.
Update: Some people have suggested other analogies. One is "lynch mob" instead of "witch hunt". Another is "cry wolf": Google deserves a lot of criticism, but when you attack them for invalid concerns, you destroy your credibility.
Update: You can easily counter the argument of this post by demonstrating how Google can use that overcollected data for evil.
Update: Some people have suggested other analogies. One is "lynch mob" instead of "witch hunt". Another is "cry wolf": Google deserves a lot of criticism, but when you attack them for invalid concerns, you destroy your credibility.
Update: You can easily counter the argument of this post by demonstrating how Google can use that overcollected data for evil.
One of the myths of CISPA (cybersecurity law) is that organizations do not have to share data with the government, that it's voluntary. The reality is that the government has lots of ways to pressure individuals/companies into volunteering.
In 2007, the FBI showed up at my office because of a speech I was to give two days later at BlackHat (the most important cybersecurity conference). They wanted me to cancel my talk because it was a threat to national security. This was crap: it was a threat to TippingPoint (I demonstrated how reverse engineering their signatures could disclose 0day vuln info). After trying to bribe me and threaten me to cancel my talk, TippingPoint got the FBI to do their dirty work.
It was a surreal experience. On one hand, the FBI kept repeating that they couldn't tell me to cancel my BlackHat talk, because we live in a free country with the First Amendment. On the other hand, they made it clear that if I did not "do the right thing" they would taint my FBI file so that I could never pass a background check, and could never work for the government again.
The FBI does the same thing when investigating cybercrime. If an organization doesn't voluntarily share with them the data on their servers, they get a broad warrant to come in and grab all computer equipment, regardless if it's related to the crime they are investigating or not.
Even if a site thinks there is only a 10% chance might obtain a warrant, it still has to comply, because that's a 10% chance they could kill the business.
The government is incompetent at cybersecurity. They are less able to secure their own systems than the private sector. Sharing private information with the government isn't going to change this -- this bill just provides a conduit for the government to get more information about its citizens that other laws (and the Bill of Rights) currently block.
Update: Some have questioned the relevance of this story to CISPA. The point is that they can intimidate you into volunteering. I'm an individual who stood up to the FBI on principle, but businesses won't. Almost all will opt-in to the CISPA data, because the government will make them an offer they can't refuse.
Update: Here is an example where the FBI first came and asked nicely for data, and when stimied, came back later and confiscated the servers: http://www.infosecisland.com/blogview/21186-FBI-Overreaches-with-May-First-Riseup-Server-Seizure.html.
Update: The Economist agrees that government will coerce companies into sharing data.
In 2007, the FBI showed up at my office because of a speech I was to give two days later at BlackHat (the most important cybersecurity conference). They wanted me to cancel my talk because it was a threat to national security. This was crap: it was a threat to TippingPoint (I demonstrated how reverse engineering their signatures could disclose 0day vuln info). After trying to bribe me and threaten me to cancel my talk, TippingPoint got the FBI to do their dirty work.
It was a surreal experience. On one hand, the FBI kept repeating that they couldn't tell me to cancel my BlackHat talk, because we live in a free country with the First Amendment. On the other hand, they made it clear that if I did not "do the right thing" they would taint my FBI file so that I could never pass a background check, and could never work for the government again.
The FBI does the same thing when investigating cybercrime. If an organization doesn't voluntarily share with them the data on their servers, they get a broad warrant to come in and grab all computer equipment, regardless if it's related to the crime they are investigating or not.
Even if a site thinks there is only a 10% chance might obtain a warrant, it still has to comply, because that's a 10% chance they could kill the business.
The government is incompetent at cybersecurity. They are less able to secure their own systems than the private sector. Sharing private information with the government isn't going to change this -- this bill just provides a conduit for the government to get more information about its citizens that other laws (and the Bill of Rights) currently block.
Update: Some have questioned the relevance of this story to CISPA. The point is that they can intimidate you into volunteering. I'm an individual who stood up to the FBI on principle, but businesses won't. Almost all will opt-in to the CISPA data, because the government will make them an offer they can't refuse.
Update: Here is an example where the FBI first came and asked nicely for data, and when stimied, came back later and confiscated the servers: http://www.infosecisland.com/blogview/21186-FBI-Overreaches-with-May-First-Riseup-Server-Seizure.html.
Update: The Economist agrees that government will coerce companies into sharing data.
I haven't been maintaining my Ferret program because I've been working a rewrite of the core engine that is super-duper. But then, my rewrite got too ambitious and it's in a state of perpetual incompleteness. Sigh.
So I've gone back and fixed the bugs with the original Ferret. In particular, 64-bit is the major issue. There is a bug preventing it from working on 64-bit. I've fixed the bug and now it seems to work just fine.
I've checked it into http://ferret.googlecode.com. If you are a developer, I can add you to the list of contributors.
Also, I've made it link to "libSegFault.so", which should print out more useful crash dumps. If it crashes, you can send that output to me (robert_david_graham@yahoo.com).
So I've gone back and fixed the bugs with the original Ferret. In particular, 64-bit is the major issue. There is a bug preventing it from working on 64-bit. I've fixed the bug and now it seems to work just fine.
I've checked it into http://ferret.googlecode.com. If you are a developer, I can add you to the list of contributors.
Also, I've made it link to "libSegFault.so", which should print out more useful crash dumps. If it crashes, you can send that output to me (robert_david_graham@yahoo.com).
As reported by Wired, the programmer who stole code from Goldman-Sachs had his conviction overturned because "code is not physical property", implying that it's somehow above the law, that there is some sort of right to open source code. That's an incorrect interpretation of the decision. The conviction was overturned because of technicalities, while the laws may have been intended to cover to this theft of code, their wording is outdated and cannot be stretched to cover this incident.
The decision says:
It clarifies later that the NSPA wording clearly means "physical good", and not intangible goods. It cites similar cases, such as bootleg recordings also being intangible goods not covered by the NSPA.
The ruling says that congress could easily amend the NSPA to include intangible goods. It's not that intangible goods are special and above the law, the issue is simply that the court doesn't find that the wording of the NSPA covers intangible goods.
The ruling likewise found that the crime didn't fall under the Economic Espionage Act (EEA) because the source code wasn't used for interstate or international commerce. The source code in question was for high-speed trading by Goldamn-Sachs, something that happened within the state of New York. Again, the court finds that while law makers might've intended to cover this theft of secrets, the fact that they specifically mention "interstate commerce" means that the law doesn't technically cover this incident.
People on Twitter are interpreting this as meaning that "code" is somehow above the law, that there is some natural right that code must be free and open. The ruling specifically tries to dispel this interpretation. It says only that the wording of existing laws doesn't cover this specific case, and that a minor change in wording would've covered it.
BTW, I'm not criticizing the above article. The article makes the same points I make. It's just that people can't read, and make assumptions without paying attention to the article itself.
The decision says:
the source code was not a "stolen" "good" within the meaning of the National Stolen Property Act (NSPA)
It clarifies later that the NSPA wording clearly means "physical good", and not intangible goods. It cites similar cases, such as bootleg recordings also being intangible goods not covered by the NSPA.
The ruling says that congress could easily amend the NSPA to include intangible goods. It's not that intangible goods are special and above the law, the issue is simply that the court doesn't find that the wording of the NSPA covers intangible goods.
The ruling likewise found that the crime didn't fall under the Economic Espionage Act (EEA) because the source code wasn't used for interstate or international commerce. The source code in question was for high-speed trading by Goldamn-Sachs, something that happened within the state of New York. Again, the court finds that while law makers might've intended to cover this theft of secrets, the fact that they specifically mention "interstate commerce" means that the law doesn't technically cover this incident.
People on Twitter are interpreting this as meaning that "code" is somehow above the law, that there is some natural right that code must be free and open. The ruling specifically tries to dispel this interpretation. It says only that the wording of existing laws doesn't cover this specific case, and that a minor change in wording would've covered it.
BTW, I'm not criticizing the above article. The article makes the same points I make. It's just that people can't read, and make assumptions without paying attention to the article itself.
But over the years, Slashdot as slid into irrelevancy. It remained largely unchanged for 15 years while other sites innovated. The "Slashdot" effect is more likely to come from Reddit, Twitter, or YCombinator than it is from Slashdot itself.
The "nail in the coffin" for Slashdot was the Jan 18 SOPA/PIPA protest. As other sites blacked out, like Wikipedia and Reddit, Slashdot continued business as usual. It mentioned the blackout, but only as yet another story that hackers might be interested in. It failed to participate in the hacker cause, as it would've at its height.
Slashdot actually died last August 2011 when its founder Rob "CmdrTaco" Malda finally quit. But we didn't realize it had died. For all we knew, he could've passed the torch to the next generation of smart hackers. But the lack of a Jan 18 blackout or April Fools pranks prove otherwise. The lights are on, but nobody is home. Its corporate owner is leaving the servers on as long as advertising pays for it, but is doing nothing else to the site.
Slashdot was on life support even before CmdTaco left. The wannabes had long ago chased away the real hackers. Once the leader in comment moderation, it now fails to separate signal from noise. It once decided to cap moderation at a measly +5 points, but that's now that's too few. Comments appealing to popular prejudices ("Microsoft is evil") quickly get those +5 points for being "insightful", drowning out truly insightful comments. In contrast, comment moderation actually works on Reddit and StackExchange. Moreover, your "karma" or "ranking" on these sites is what matters. People are even putting their ranking on StackExchange on their resumes, to demonstrate their mastery in their field.
I've been Slashdotted around once a year since 1998, back when I served my site from a DSL line on a Pentium 90-MHz server. Nowadays, even when one of my blog posts makes it onto the Slashdot front page, I'll still get more hits coming from Reddit or YCombinator or Twitter or Facebook.
For hackers, there is a lesson here: innovate or die. Slashdot was so afraid of losing existing readers that it failed to make necessary changes to attract new readers. The Internet is a source of constant revolution – no matter how many years you are ahead of the competition, they will catch up, and they will surpass you. The new "Slashdotted" is what they did to themselves – remain static for 15 years while everything else passed them by.
So Slashdot, I'll miss you. In the dotcom boom, your nerd news indeed mattered. I visited your site several times a day to see what was going on. I eagerly read what other hackers had to say about a story, and I competed to write original, interesting comments myself to max out my karma. But these days, visiting your site is a painful experience, like going back to the town where you grew up where everyone you knew has moved away.
R.I.P 2012
Alan Shimmel has a post claiming If The Best Technology Won We Would All Be Using OS/2. It’s not true, OS/2 wasn’t the best technology. And in any case, we are still using it.
OS/2 was only a 16-bit operating system when it was released in 1987. Sure, it was better than MS-DOS, but it was already behind the Amiga and Xenix, a Unix variant that ran in a full 32-bits on the 80386.
It wouldn’t be until 1992 that OS/2 would go a full 32-bits. By that time, IBM and Microsoft had forked the source code. The disagreement was over support of the Windows APIs. By this time, Windows had become too popular to ignore. By adding the APIs to OS/2, porting applications from 16-bits to 32-bits would be a minor code change. But not having the APIs would force a complete rewrite.
Thus, "IBM OS/2 Warp" became the 32-bit version without Windows compatibility, and "Microsoft Windows NT" (or simply "WinNT") was the version with Windows compatibility. Note that WinNT was not Windows, it was instead OS/2 with Windows backwards compatibility.
Even today, we retain many OS/2-isms in WinNT (now known as Windows 7). For example, "beginthread" is an OS/2 API. OS/2 had threads from the beginning, but Windows never did, so the threading APIs are naturally the OS/2 APIs. Some networking vulnerabilities (in SMB) actually come from OS/2.
Their first 32-bit versions (OS/2 2.0 vs WinNT 3.1) competed head-to-head in 1993. OS/2 had strengths, such as running older MS-DOS programs, but on the whole, WinNT was a much better technology in almost every other aspect, quite apart from it’s backwards compatibility with the Windows API.
Superior technology is rarely superior, but is instead a choice of tradeoffs. The Beta vs VHS war is a good example. Beta had twice the video quality as VHS, and is described as "better". But it had half the run time, so you couldn’t fit an entire movie on a single Beta tape. Beta lost because customers didn’t like the tradeoff, not because somehow VHS tricked people.
But sometime a product does make a huge advance. A good example is the Commodore Amiga. It was a generation ahead of any competing system when it was released in 1985, which is why it’s fondly remembered even today.
A similar thing happened in 1996 with the Microsoft/Intel alliance. Intel started shipping its "Pentium Pro" microprocessor, which was faster on every relevant benchmark than competing RISC processors. At the same time, Microsoft released WinNT 4.0, which was faster on every "C10K" style benchmark than any competing Unix operating system. In addition, you could cheaply put two Pentium Pro processors into a system for little more than price of one, and WinNT 4.0 supported both processors. WinNT then became Win2k, then WinXP, then now Win7.
The conclusion is this: back in late 1980s, the only thing OS/2 was better than was MS-DOS. But it did evolve into WinNT, which eventually did win because it was indeed the superior technology.
Diclaimer: My first job out of college in 1990 was programming on OS/2. It was much better than MS-DOS, but it's 16-bit nature was a pain. By 1994, I was programming on WinNT, which has been my favorite environment since, despite the fact that most of my code runs on Linux.
OS/2 was only a 16-bit operating system when it was released in 1987. Sure, it was better than MS-DOS, but it was already behind the Amiga and Xenix, a Unix variant that ran in a full 32-bits on the 80386.
It wouldn’t be until 1992 that OS/2 would go a full 32-bits. By that time, IBM and Microsoft had forked the source code. The disagreement was over support of the Windows APIs. By this time, Windows had become too popular to ignore. By adding the APIs to OS/2, porting applications from 16-bits to 32-bits would be a minor code change. But not having the APIs would force a complete rewrite.
Thus, "IBM OS/2 Warp" became the 32-bit version without Windows compatibility, and "Microsoft Windows NT" (or simply "WinNT") was the version with Windows compatibility. Note that WinNT was not Windows, it was instead OS/2 with Windows backwards compatibility.
Even today, we retain many OS/2-isms in WinNT (now known as Windows 7). For example, "beginthread" is an OS/2 API. OS/2 had threads from the beginning, but Windows never did, so the threading APIs are naturally the OS/2 APIs. Some networking vulnerabilities (in SMB) actually come from OS/2.
Their first 32-bit versions (OS/2 2.0 vs WinNT 3.1) competed head-to-head in 1993. OS/2 had strengths, such as running older MS-DOS programs, but on the whole, WinNT was a much better technology in almost every other aspect, quite apart from it’s backwards compatibility with the Windows API.
Superior technology is rarely superior, but is instead a choice of tradeoffs. The Beta vs VHS war is a good example. Beta had twice the video quality as VHS, and is described as "better". But it had half the run time, so you couldn’t fit an entire movie on a single Beta tape. Beta lost because customers didn’t like the tradeoff, not because somehow VHS tricked people.
But sometime a product does make a huge advance. A good example is the Commodore Amiga. It was a generation ahead of any competing system when it was released in 1985, which is why it’s fondly remembered even today.
A similar thing happened in 1996 with the Microsoft/Intel alliance. Intel started shipping its "Pentium Pro" microprocessor, which was faster on every relevant benchmark than competing RISC processors. At the same time, Microsoft released WinNT 4.0, which was faster on every "C10K" style benchmark than any competing Unix operating system. In addition, you could cheaply put two Pentium Pro processors into a system for little more than price of one, and WinNT 4.0 supported both processors. WinNT then became Win2k, then WinXP, then now Win7.
The conclusion is this: back in late 1980s, the only thing OS/2 was better than was MS-DOS. But it did evolve into WinNT, which eventually did win because it was indeed the superior technology.
Diclaimer: My first job out of college in 1990 was programming on OS/2. It was much better than MS-DOS, but it's 16-bit nature was a pain. By 1994, I was programming on WinNT, which has been my favorite environment since, despite the fact that most of my code runs on Linux.
There was no #Anonymous blackout on March 31. For example, here is a graph for traffic to one of those servers. As you can see, there is no unusual traffic today (Saturday, the far right of the graph). This Saturday's traffic looks little different than last Saturday's (to the left).
As to whether the threat was "real" is a philosophical question. Many famous #Anonymous identities (e.g. @YourAnonNews) disavowed it. But there is no single official "Anonymous", so nobody truly has the authority to disavow it. If enough people undertake the attack in the name of "Anonymous", then it's a "real" attack, regardless if some others disagree.
With that said, there was no easy download of the "ramp" tool. There was no link to it in the original PasteBin post that announced the attack. The whole point of DDoS is to distribute your tool to as many many people as possible so they can all attack the target. No tool distribution means no attack. Whether the person who authored the original PasteBin link intended to follow up with a posting of the "ramp" tool is an unanswered question. The number of people that would've downloaded and run the tool is likewise an unanswered question.
I tend to agree that it probably wouldn't have been popular in the #Anonymous community. And, as I pointed out earlier, it probably wouldn't have worked even with the full weight of #Anonymous behind it.
As to whether the threat was "real" is a philosophical question. Many famous #Anonymous identities (e.g. @YourAnonNews) disavowed it. But there is no single official "Anonymous", so nobody truly has the authority to disavow it. If enough people undertake the attack in the name of "Anonymous", then it's a "real" attack, regardless if some others disagree.
With that said, there was no easy download of the "ramp" tool. There was no link to it in the original PasteBin post that announced the attack. The whole point of DDoS is to distribute your tool to as many many people as possible so they can all attack the target. No tool distribution means no attack. Whether the person who authored the original PasteBin link intended to follow up with a posting of the "ramp" tool is an unanswered question. The number of people that would've downloaded and run the tool is likewise an unanswered question.
I tend to agree that it probably wouldn't have been popular in the #Anonymous community. And, as I pointed out earlier, it probably wouldn't have worked even with the full weight of #Anonymous behind it.
As a Libertarian, I of course believe that employers are free to ask for your Facebook password, and that you are free to refuse. This also could be because I'm a conceited jerk who believes that any employer would be lucky to hire me, so I believe I have the upper hand in the power struggle.
But completely separate from that, giving your employer your Facebook password does not give them the right to use the password. In fact, using the password to logon could be considered a crime, such as "computer fraud and abuse" or "identity theft".
Facebook's current legal terms say this:
That means you are in violation of those terms if you give your password to your prospective employer. But, hypothetically, Facebook could add to their terms:
This makes it clear that logging into somebody else's account is identity theft, which means employers can be prosecuted under existing fraud and abuse laws. Facebook could just monitor multiple logins from a single location of unrelated accounts, and then send the police to go arrest the employer.
Of course, employers can respond by insisting that users log onto their own accounts during the interview process, but this is still an improvement. Presumably if one employer rejects you because those drunken nude party photos, you could remove them before the next job interview.
But completely separate from that, giving your employer your Facebook password does not give them the right to use the password. In fact, using the password to logon could be considered a crime, such as "computer fraud and abuse" or "identity theft".
Facebook's current legal terms say this:
You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
That means you are in violation of those terms if you give your password to your prospective employer. But, hypothetically, Facebook could add to their terms:
A account may be accessed only by its owner, by logging in you agree that you are the person who owns the account.
This makes it clear that logging into somebody else's account is identity theft, which means employers can be prosecuted under existing fraud and abuse laws. Facebook could just monitor multiple logins from a single location of unrelated accounts, and then send the police to go arrest the employer.
Of course, employers can respond by insisting that users log onto their own accounts during the interview process, but this is still an improvement. Presumably if one employer rejects you because those drunken nude party photos, you could remove them before the next job interview.
In the news, it appears that Chinese hackers got hold of the secret proof-of-concept (PoC) exploit for the recent Microsoft RDP bug. The most likely culprit was Microsoft’s MAPP program, which gives PoCs to security vendors 24 hours ahead of the patch so that they update their products to protect against the bug, to provide "zero-day" protection.
The MAPP program and zero-day protection is largely a scam. Vendors don’t use the provided PoCs to protect against the underlying vuln. Instead, vendors just write signatures that trigger on the PoC itself, but which are unlikely to detect exploits written by hackers that appear later in the wild.
In other words, MAPP’s PoCs are more likely to leak out and help hackers than they are to help IPS vendors.
Take, for example, the TippingPoint IPS. It is based on "pattern-matching" technology, which means most of their signatures trigger on known exploits rather than the underlying vuln. That means when they release "zero-day" protection, they are really just triggering on the MAPP PoC. Yet, they mislead there to customers about this. Their RDP advisory promises "TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter ID 12138".
The truth is that the only zero-day protection they provide is against the MAPP PoC that was leaked to the Chinese hackers, not to the underlying vulnerability itself.
Not all vendors lie. Compare the TippingPoint inflated claims of protection with the equivalent Symantec RDP advisory which says "This signature detects attempts to exploit a remote code execution vulnerability in Microsoft RDP".
Sure, the language is a bit confusing, and can be interpreted as meaning "the vulnerability". But the slight change in wording means that the only thing they are promising is protection against the one known exploit (the MAPP PoC).
To protect against the vulnerability, and not just known exploits, you have to write code that decodes the RDP protocol. The vulnerability is in the "maxChannelIds" field, which is encoded with "BER". The typical encoding would look like "02 01 00", but Luigi Auriemmia (the creator of the PoC) change the encoding to be "02 04 00 00 00 00". This is how he knows it was his PoC – the packet used in the Chinese exploit contained all his changes.
Here is a list of some of the infinite number of encodings for this field:
Which of these encodings trigger the TippingPoint filter 12138? If only the first couple encodings trigger, then TippingPoint is lying about providing zero-day protection of the vulnerability. If all the above encodings trigger, then they are probably telling the truth.
Beware that you can’t actually use those 5 patterns I list above. The last time I made this criticism, TippingPoint simply added my patterns to their signature list, thus passing my test. So you have to use valid encodings of BER integers that aren’t already published. (You have no idea how irritating it is to reverse engineer a TippingPoint box only to find signatures that trigger only on a pattern discussed in a PowerPoint slide about how to change patterns to evade detection).
If somebody has a TippingPoint box (or any other IDS/IPS) that I can access remotely, I’d love to try this out. I’ll just grab the PoC, make some changes to the protocol, and see if the box triggers.
Full disclosure: I have worked with MAPP PoCs in the past. Back then, we struggled to create good "vulnerability" signatures that detected all possible variations. The process wasn't perfect, but we'd catch 0day exploits with different patterns about 2 times out of 3. This is far better than the crappy competing signatures that would trigger on the "AAAA" pattern designed to get EIP at 0x41414141 (i.e. hackers would have to change the pattern to something other than "AAAA" to get it to work -- which means by definition, the signature could never detect anything other than the PoC).
The MAPP program and zero-day protection is largely a scam. Vendors don’t use the provided PoCs to protect against the underlying vuln. Instead, vendors just write signatures that trigger on the PoC itself, but which are unlikely to detect exploits written by hackers that appear later in the wild.
In other words, MAPP’s PoCs are more likely to leak out and help hackers than they are to help IPS vendors.
Take, for example, the TippingPoint IPS. It is based on "pattern-matching" technology, which means most of their signatures trigger on known exploits rather than the underlying vuln. That means when they release "zero-day" protection, they are really just triggering on the MAPP PoC. Yet, they mislead there to customers about this. Their RDP advisory promises "TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter ID 12138".
The truth is that the only zero-day protection they provide is against the MAPP PoC that was leaked to the Chinese hackers, not to the underlying vulnerability itself.
Not all vendors lie. Compare the TippingPoint inflated claims of protection with the equivalent Symantec RDP advisory which says "This signature detects attempts to exploit a remote code execution vulnerability in Microsoft RDP".
Sure, the language is a bit confusing, and can be interpreted as meaning "the vulnerability". But the slight change in wording means that the only thing they are promising is protection against the one known exploit (the MAPP PoC).
To protect against the vulnerability, and not just known exploits, you have to write code that decodes the RDP protocol. The vulnerability is in the "maxChannelIds" field, which is encoded with "BER". The typical encoding would look like "02 01 00", but Luigi Auriemmia (the creator of the PoC) change the encoding to be "02 04 00 00 00 00". This is how he knows it was his PoC – the packet used in the Chinese exploit contained all his changes.
Here is a list of some of the infinite number of encodings for this field:
02 04 00 00 00 00
02 01 00
02 02 00 00
02 81 03 00 00 00
02 84 00 00 00 08 00 00 00 00 00 00 00 00
Which of these encodings trigger the TippingPoint filter 12138? If only the first couple encodings trigger, then TippingPoint is lying about providing zero-day protection of the vulnerability. If all the above encodings trigger, then they are probably telling the truth.
Beware that you can’t actually use those 5 patterns I list above. The last time I made this criticism, TippingPoint simply added my patterns to their signature list, thus passing my test. So you have to use valid encodings of BER integers that aren’t already published. (You have no idea how irritating it is to reverse engineer a TippingPoint box only to find signatures that trigger only on a pattern discussed in a PowerPoint slide about how to change patterns to evade detection).
If somebody has a TippingPoint box (or any other IDS/IPS) that I can access remotely, I’d love to try this out. I’ll just grab the PoC, make some changes to the protocol, and see if the box triggers.
Full disclosure: I have worked with MAPP PoCs in the past. Back then, we struggled to create good "vulnerability" signatures that detected all possible variations. The process wasn't perfect, but we'd catch 0day exploits with different patterns about 2 times out of 3. This is far better than the crappy competing signatures that would trigger on the "AAAA" pattern designed to get EIP at 0x41414141 (i.e. hackers would have to change the pattern to something other than "AAAA" to get it to work -- which means by definition, the signature could never detect anything other than the PoC).
You'd think that politics has nothing to do with cybersecurity, but it does. You can often guess a person's political leanings by their opinions on cybersecurity.
For example, I'm a Libertarian. Because of this, I oppose concepts like "defense in depth". I claim that "the Internet is secure enough", and that "cybersecurity is a tradeoff". These things just flow unsurprisingly from the Libertarian way of looking at the world.
Therefore, I assumed McCain would be better than Obama at helping cybersecurity regulation. McCain talked about the old nasty telcoms regulation that stifled early Internet growth. He demonstrated understanding of the way laws killed innovation,. even though he didn't understand the Internet itself. Conversely, Obama preached how government was going to change the Internet for the better. I think think government can do little to make the Internet better, but can inadvertently do much to make things much worse, so I endorsed McCain. A fatuous thing to do, of course, but since Google endorsed Obama, I went ahead with it.
But the reverse happened. Obama has been largely "hands-off" on the Internet, letting the DHS, NSA, and DoD fight their turf war to see who'd get control of cyberspace. Meanwhile, McCain has been pushing exactly the sort of legislation I feared most, such as his recently introduced cybersecurity bill, described by some as "Orwellian" the way it gives government control over the Internet. McCain was also one of the chief sponsors of the NDAA amendment that authorizes the president to suspend habeas corpus (not precisely cybersec related, but something every cybersec person I know opposes). [My libertarian friends chide me, pointing out that McCains attacks on free-speech in the past demonstrated that he didn't really believe in civil liberties, so that I should've known.]
So I was wrong about McCain, so very very wrong.
This post is just to jot down interest bits of info on the Sabu arrest. All the good stories with details appear in the first few hours, then the Internet fills up with crud, and I can no longer find the original stories via Google.
Fox News as the original stories at these links:
http://www.foxnews.com/scitech/2012/03/06/hacking-group-lulzsec-swept-up-by-law-enforcement/
http://www.foxnews.com/scitech/2012/03/06/exclusive-inside-lulzsec-mastermind-turns-on-his-minions/
http://www.foxnews.com/scitech/2012/03/06/exclusive-unmasking-worlds-most-wanted-hacker/
They caught him because just once, he logged onto IRC without going through Tor, revealing to the FBI his IP address. This reveals a little bit about the FBI, namely that they've infiltrated enough of the popular IRC relays to be able to get people's IP addresses. We've always suspected they could, now we know.
This is a good lesson for Tor users. Tor, itself, is not enough to keep your identity hidden. It "fails open", which means that if you make a mistake, you'll expose your IP address. If "they" are coming after you, you need to configure a "fail close" network setup, such as by using a second machine as a transparent Tor proxy, such that everything is forced through Tor no matter what you do, and if the Tor service fails, your network connectivity also fails (fail close). Update: Two commenters think I'm criticizing Tor. I'm not. It's like that fact that crypto isn't enough to keep your data private. The FBI cannot crack AES128, but if you've chosen a poor password, they can crack that. It's not AES128's fault you chose a bad password. It's likewise not Tor's fault you bypassed it in order to log onto IRC. It's just that you should be aware of the importance of choosing good passwords, and practicing good Tor hygiene.
Another lesson about the FBI is that this is how they always work. You don't expect arrests right away after a major hack. Instead, the FBI will plod along for a year infiltrating as much of the organization as they can, turning key members, gathering hard evidence, and THEN they swoop in and gather everyone up.
This is mostly because hard evidence of past crimes is hard to get. You need evidence of future crimes. Once you've infiltrated the organization and can monitor what they are doing in real time, you'll get evidence of the crimes as they are happening, evidence you couldn't get on their previous crimes.
And the evidence the FBI most wants is for things like "conspiracy" [most of those arrested today are indicted on conspiracy]. Proving you committed a crime is hard, proving you conspired to commit it (by monitoring IRC) is pretty easy. Unless they find the stolen credit card numbers on your laptop, they'll find it difficult convicting you of cybercrime. But they can convict you of conspiracy, intent, obstruction of of justice, racketeering, and so on. For example, the Palin hacker was convicted of only misdemeanor hacking, but felony obstruction of justice because he deleted evidence of the hack.
When your little group has done something really bad, and you realize you've gotten over your head and the the FBI is coming after you, you have the prisoner's dilemma to consider. The first one of you that cracks and helps the FBI track everyone else down will get the sweetheart deal, and everyone else will go to jail. I can't see myself doing this, but at the same time, I can't see myself getting involved in such cybercrime.
Anyway, this is just my notes page. As my stories appear on this subject, I'm going to keep updating this post.
--
From the Jimmy Graham in the comments section comes this article (http://www.informationweek.com/news/security/attacks/231000584) from last June that outed Sabu's identity. It points to this pastebin (http://pastebin.com/iVujX4TR) which dumps some key data on their identities. I'm surprised we all missed this back then.
--
Official FBI press statement: http://www.fbi.gov/newyork/press-releases/2012/six-hackers-in-the-united-states-and-abroad-charged-for-crimes-affecting-over-one-million-victims
---
Post from IBtimes (http://www.ibtimes.co.uk/articles/293742/20120206/antisec-anonymous-hackers-fbi-anti-security-hack.htm) from a month ago that looks completely different now that this has been revealed.
---
Post from The Guardian (http://www.guardian.co.uk/technology/2012/mar/06/lulzsec-sabu-working-for-us-fbi?CMP=twt_gu) that regurgitates the Fox News article, though they have some good links to their past coverage of Sabu, such as this article (http://www.guardian.co.uk/technology/2011/jun/24/inside-lulzsec-chatroom-logs-hackers) from last June (around the time Sabu was secretly arrested) discussing leaked chat logs of the LulzSec group.
--
This document (http://blog.wearpants.org/media/namshub.pdf) outs a lot of Anonymous, I'm not sure when it was posted, but it apparently identified Sabu before today's announcement.
--
This post from last December (http://rickey-g.blogspot.com/2011/12/anonymousabu-aka-xavier-de-leon.html) finds some clues to Sabu's identity, which in hindsight, appear to be true.
--
Wild eye ravings? Is FBI and/or Anymous behind everything? (http://www.deathandtaxesmag.com/179764/anonymous-has-grown-beyond-lulzsec-and-sabu/) Dispels the more extreme notions of the FBI, but still assumes that that the FBI is controlled by corporate/political interests.
--
A paper written describing what LulzSec is: http://pastehtml.com/view/blpmqrn78.html
--
Six things you didn't know about Sabu: http://www.buzzfeed.com/jwherrman/five-things-you-didnt-know-about-sabu-the-lulzse
--
Sabu's indictment: http://www.nypost.com/rw/nypost/2012/03/06/media/030612_hackers.pdf
--
Sabu assumed he was an FBI agent, rather than just a CI: http://gawker.com/5890901/anonymous-snitch-tried-and-failed-to-pass-himself-off-as-an-fbi-agent-last-month (Has he never watched "White Collar" TV show??)
--
Barret Brown, who sometimes acts as a spokesman, had his house raided :http://www.nytimes.com/2012/03/07/technology/lulzsec-hacking-suspects-are-arrested.html?_r=3
--
Interesting Gawker piece (http://gizmodo.com/5890825/lulzsec-leader-betrays-all-of-anonymous) with chat logs with "Virus", a detractor of Sabu who has been claiming Sabu was a snitch nearly from the moment Sabu became a snitch.
--
Great piece from Ars Technica on how Sabu led them to Hammond: http://arstechnica.com/tech-policy/news/2012/03/stakeout-how-the-fbi-tracked-and-busted-a-chicago-anon.ars
--
Fox News as the original stories at these links:
http://www.foxnews.com/scitech/2012/03/06/hacking-group-lulzsec-swept-up-by-law-enforcement/
http://www.foxnews.com/scitech/2012/03/06/exclusive-inside-lulzsec-mastermind-turns-on-his-minions/
http://www.foxnews.com/scitech/2012/03/06/exclusive-unmasking-worlds-most-wanted-hacker/
They caught him because just once, he logged onto IRC without going through Tor, revealing to the FBI his IP address. This reveals a little bit about the FBI, namely that they've infiltrated enough of the popular IRC relays to be able to get people's IP addresses. We've always suspected they could, now we know.
This is a good lesson for Tor users. Tor, itself, is not enough to keep your identity hidden. It "fails open", which means that if you make a mistake, you'll expose your IP address. If "they" are coming after you, you need to configure a "fail close" network setup, such as by using a second machine as a transparent Tor proxy, such that everything is forced through Tor no matter what you do, and if the Tor service fails, your network connectivity also fails (fail close). Update: Two commenters think I'm criticizing Tor. I'm not. It's like that fact that crypto isn't enough to keep your data private. The FBI cannot crack AES128, but if you've chosen a poor password, they can crack that. It's not AES128's fault you chose a bad password. It's likewise not Tor's fault you bypassed it in order to log onto IRC. It's just that you should be aware of the importance of choosing good passwords, and practicing good Tor hygiene.
Another lesson about the FBI is that this is how they always work. You don't expect arrests right away after a major hack. Instead, the FBI will plod along for a year infiltrating as much of the organization as they can, turning key members, gathering hard evidence, and THEN they swoop in and gather everyone up.
This is mostly because hard evidence of past crimes is hard to get. You need evidence of future crimes. Once you've infiltrated the organization and can monitor what they are doing in real time, you'll get evidence of the crimes as they are happening, evidence you couldn't get on their previous crimes.
And the evidence the FBI most wants is for things like "conspiracy" [most of those arrested today are indicted on conspiracy]. Proving you committed a crime is hard, proving you conspired to commit it (by monitoring IRC) is pretty easy. Unless they find the stolen credit card numbers on your laptop, they'll find it difficult convicting you of cybercrime. But they can convict you of conspiracy, intent, obstruction of of justice, racketeering, and so on. For example, the Palin hacker was convicted of only misdemeanor hacking, but felony obstruction of justice because he deleted evidence of the hack.
When your little group has done something really bad, and you realize you've gotten over your head and the the FBI is coming after you, you have the prisoner's dilemma to consider. The first one of you that cracks and helps the FBI track everyone else down will get the sweetheart deal, and everyone else will go to jail. I can't see myself doing this, but at the same time, I can't see myself getting involved in such cybercrime.
Anyway, this is just my notes page. As my stories appear on this subject, I'm going to keep updating this post.
--
From the Jimmy Graham in the comments section comes this article (http://www.informationweek.com/news/security/attacks/231000584) from last June that outed Sabu's identity. It points to this pastebin (http://pastebin.com/iVujX4TR) which dumps some key data on their identities. I'm surprised we all missed this back then.
--
Official FBI press statement: http://www.fbi.gov/newyork/press-releases/2012/six-hackers-in-the-united-states-and-abroad-charged-for-crimes-affecting-over-one-million-victims
---
Post from IBtimes (http://www.ibtimes.co.uk/articles/293742/20120206/antisec-anonymous-hackers-fbi-anti-security-hack.htm) from a month ago that looks completely different now that this has been revealed.
---
Post from The Guardian (http://www.guardian.co.uk/technology/2012/mar/06/lulzsec-sabu-working-for-us-fbi?CMP=twt_gu) that regurgitates the Fox News article, though they have some good links to their past coverage of Sabu, such as this article (http://www.guardian.co.uk/technology/2011/jun/24/inside-lulzsec-chatroom-logs-hackers) from last June (around the time Sabu was secretly arrested) discussing leaked chat logs of the LulzSec group.
--
This document (http://blog.wearpants.org/media/namshub.pdf) outs a lot of Anonymous, I'm not sure when it was posted, but it apparently identified Sabu before today's announcement.
--
This post from last December (http://rickey-g.blogspot.com/2011/12/anonymousabu-aka-xavier-de-leon.html) finds some clues to Sabu's identity, which in hindsight, appear to be true.
--
Wild eye ravings? Is FBI and/or Anymous behind everything? (http://www.deathandtaxesmag.com/179764/anonymous-has-grown-beyond-lulzsec-and-sabu/) Dispels the more extreme notions of the FBI, but still assumes that that the FBI is controlled by corporate/political interests.
--
A paper written describing what LulzSec is: http://pastehtml.com/view/blpmqrn78.html
--
Six things you didn't know about Sabu: http://www.buzzfeed.com/jwherrman/five-things-you-didnt-know-about-sabu-the-lulzse
--
Sabu's indictment: http://www.nypost.com/rw/nypost/2012/03/06/media/030612_hackers.pdf
--
Sabu assumed he was an FBI agent, rather than just a CI: http://gawker.com/5890901/anonymous-snitch-tried-and-failed-to-pass-himself-off-as-an-fbi-agent-last-month (Has he never watched "White Collar" TV show??)
--
Barret Brown, who sometimes acts as a spokesman, had his house raided :http://www.nytimes.com/2012/03/07/technology/lulzsec-hacking-suspects-are-arrested.html?_r=3
--
Interesting Gawker piece (http://gizmodo.com/5890825/lulzsec-leader-betrays-all-of-anonymous) with chat logs with "Virus", a detractor of Sabu who has been claiming Sabu was a snitch nearly from the moment Sabu became a snitch.
--
Great piece from Ars Technica on how Sabu led them to Hammond: http://arstechnica.com/tech-policy/news/2012/03/stakeout-how-the-fbi-tracked-and-busted-a-chicago-anon.ars
--
Sabu's Reddit Ask-Me-Anything thread, Sep'11:reddit.com/r/IAmA/comment… "Stick to yourselves. Friends will try to take you down if they have to."
(Update: this post is not obsolete, as Ruby-on-Rails is actually going to fix the problem, and this humorous post explains the controversy better than my post).
For those who don’t speak Russian or Ruby-on-Rails, I thought I’d translate the recent GitHub hack controversy.
The underlying issue is an "Insecure Direct Object Reference", #4 on the OWASP Top 10 list of most important web-application vulnerabilities. It means that that a hacker can change what's in the website database without having permission.
The cause of the GitHub hack was the toolkit/programming-language they used to build their site: Ruby-on-Rails. Ruby-on-Rails supports a feature known as "mass assignment". It means that hackers can add parameters to webrequests that don’t belong there, and they’ll be assigned to the object along with the normal parameters. In other words, your account might have a flag otherwise invisible to you like "admin=false". By including "user[admin]=true" in an otherwise innocent web request, you can give yourself administrator privileges and take over the site.
This "mass assignment" feature is pretty toxic, at least as far as cybersecurity goes. It’s one of those big features that make Ruby-on-Rails so easy to use in order to build websites. Fixing the security problem therefore makes it harder to program websites in Ruby-on-Rails, and would instantly break most existing websites built using the toolkit.
That’s why when Russian programmer Egor Homakov reported the "bug", it was rejected. The argument was that this is behaving by design, and that while it was dangerous, it was prominently described in the "Ruby On Rails Security Guide". There is a solution for programmers: "blacklist" values that should not be mass assignable, such as marking "admin" as something that causes a mass assignment to fail. In other words, it’s the owner’s responsibility to not shoot themselves in the foot, not the gun manufacturer’s.
Any cybersecurity professional knows this is wrong, but being Russian, Homakov’s English skills aren’t so good at arguing his point. So he used his hacking skills instead, and used the bug to hack into GitHub.
GitHub and Ruby-on-Rails are independent projects that are otherwise unrelated to each other. GitHub is a popular project hosting site, and it just so happens that one of the zillions of projects it hosts is "Ruby-on-Rails". On the other side, Ruby-on-Rails is a toolkit for creating websites, and it just so happens that one of the zillions of websites written with Ruby-on-Rails is "GitHub".
This gave Homakov a neat opportunity. He wanted the owners of the Ruby-on-Rails project to take him seriously, so what better way to do that than hack the very site hosting Ruby-on-Rails using the very bug he was talking about? He used the bug to hack into GitHub, and gave himself administrative control over the Ruby-on-Rails project. He used this hacked authority to then write a comment into the Ruby-on-Rails source code discussing the problem.
It took no time at all for GitHub to fix that one bug, by blacklisting the hacked value so nobody can repeat the hack. But GitHub can’t be sure that there aren’t more mass assignment problems in their source code waiting to be discovered. Given any complex website written in Ruby-on-Rails, there is a good chance you can eventually find a mass assignment bug if you try hard enough.
There are a few cybersecurity lessons here.
The first lesson is that when you own a gun that accidentally fires 1% of the time you pick it up, then you’ll eventually shoot yourself in the foot. The same is true of Ruby-on-Rail’s mass assignment: you’ll eventually shoot yourself in the foot. It’s inherently dangerous, you can’t consider it for your next big project until this bug is fixed -- and since fixing this bug will break all existing Ruby-on-Rails websites, I doubt that will ever happen.
The second lesson is that "blacklisting" doesn’t work. We’ve tried blacklisting known bad characters (like ') from SQL, and found it doesn’t stop SQL injection. We’ve tried blacklisting known bad characters (like <) from HTML, and found it doesn’t stop cross site scripting. You can’t expect programmers to correctly blacklist all variables that shouldn’t be set with mass assignment, because they’ll eventually forget one, a hacker will find it, and break in. Instead, you have to "whitelist" known safe variables, where the consequence of a programmer error is simply a bug in the website, not a hack.
The third lesson is that there is no good solution to the problem. Ruby-on-Rails already has plenty of what appear to be good solutions -- that fail. If you put "ActiveRecord::Base.send(:attr_accessible, nil)" in the file "config/initializers/disable_mass_assignment.rb", you will fix the problem the way it should be fixed. But while good for you, most programmers still won’t use it,and there will still be a pervasive problem with mass assignment. We’ve had an obvious solution to SQL injection for a decade ("parameterized queries"), but most programmers still don’t use them, so SQL injection is still the web application’s #1 problem. "Insecure direct object reference" will stay at #4, or even rise to #3, until the Ruby-on-Rails project makes a change.
The fourth lesson is understanding "ease of use". Mass assignment makes creating websites a lot easier. But it makes securing websites much harder. You lose more in security than you gain in ease-of-use of the toolkit. As the GitHub hack showed, if you are putting your site on the Internet, security isn't an option. You don't need to fix every security problem, you don't even need to fix everything in the OWASP Top 10. But if you ignore the the top 4, you are a fool.
Finally, this shows the benefit of irresponsible disclosure. Homakov possibly broke the law, or at least, behaved "unethically" according to many people’s definition. Yet, it was not malicious, and caused no harm (other than deserved harm to reputation). It was the level of "disclosure" needed to bring what I feel is necessary attention to the problem.
For those who don’t speak Russian or Ruby-on-Rails, I thought I’d translate the recent GitHub hack controversy.
The underlying issue is an "Insecure Direct Object Reference", #4 on the OWASP Top 10 list of most important web-application vulnerabilities. It means that that a hacker can change what's in the website database without having permission.
The cause of the GitHub hack was the toolkit/programming-language they used to build their site: Ruby-on-Rails. Ruby-on-Rails supports a feature known as "mass assignment". It means that hackers can add parameters to webrequests that don’t belong there, and they’ll be assigned to the object along with the normal parameters. In other words, your account might have a flag otherwise invisible to you like "admin=false". By including "user[admin]=true" in an otherwise innocent web request, you can give yourself administrator privileges and take over the site.
This "mass assignment" feature is pretty toxic, at least as far as cybersecurity goes. It’s one of those big features that make Ruby-on-Rails so easy to use in order to build websites. Fixing the security problem therefore makes it harder to program websites in Ruby-on-Rails, and would instantly break most existing websites built using the toolkit.
That’s why when Russian programmer Egor Homakov reported the "bug", it was rejected. The argument was that this is behaving by design, and that while it was dangerous, it was prominently described in the "Ruby On Rails Security Guide". There is a solution for programmers: "blacklist" values that should not be mass assignable, such as marking "admin" as something that causes a mass assignment to fail. In other words, it’s the owner’s responsibility to not shoot themselves in the foot, not the gun manufacturer’s.
Any cybersecurity professional knows this is wrong, but being Russian, Homakov’s English skills aren’t so good at arguing his point. So he used his hacking skills instead, and used the bug to hack into GitHub.
GitHub and Ruby-on-Rails are independent projects that are otherwise unrelated to each other. GitHub is a popular project hosting site, and it just so happens that one of the zillions of projects it hosts is "Ruby-on-Rails". On the other side, Ruby-on-Rails is a toolkit for creating websites, and it just so happens that one of the zillions of websites written with Ruby-on-Rails is "GitHub".
This gave Homakov a neat opportunity. He wanted the owners of the Ruby-on-Rails project to take him seriously, so what better way to do that than hack the very site hosting Ruby-on-Rails using the very bug he was talking about? He used the bug to hack into GitHub, and gave himself administrative control over the Ruby-on-Rails project. He used this hacked authority to then write a comment into the Ruby-on-Rails source code discussing the problem.
It took no time at all for GitHub to fix that one bug, by blacklisting the hacked value so nobody can repeat the hack. But GitHub can’t be sure that there aren’t more mass assignment problems in their source code waiting to be discovered. Given any complex website written in Ruby-on-Rails, there is a good chance you can eventually find a mass assignment bug if you try hard enough.
There are a few cybersecurity lessons here.
The first lesson is that when you own a gun that accidentally fires 1% of the time you pick it up, then you’ll eventually shoot yourself in the foot. The same is true of Ruby-on-Rail’s mass assignment: you’ll eventually shoot yourself in the foot. It’s inherently dangerous, you can’t consider it for your next big project until this bug is fixed -- and since fixing this bug will break all existing Ruby-on-Rails websites, I doubt that will ever happen.
The second lesson is that "blacklisting" doesn’t work. We’ve tried blacklisting known bad characters (like ') from SQL, and found it doesn’t stop SQL injection. We’ve tried blacklisting known bad characters (like <) from HTML, and found it doesn’t stop cross site scripting. You can’t expect programmers to correctly blacklist all variables that shouldn’t be set with mass assignment, because they’ll eventually forget one, a hacker will find it, and break in. Instead, you have to "whitelist" known safe variables, where the consequence of a programmer error is simply a bug in the website, not a hack.
The third lesson is that there is no good solution to the problem. Ruby-on-Rails already has plenty of what appear to be good solutions -- that fail. If you put "ActiveRecord::Base.send(:attr_accessible, nil)" in the file "config/initializers/disable_mass_assignment.rb", you will fix the problem the way it should be fixed. But while good for you, most programmers still won’t use it,and there will still be a pervasive problem with mass assignment. We’ve had an obvious solution to SQL injection for a decade ("parameterized queries"), but most programmers still don’t use them, so SQL injection is still the web application’s #1 problem. "Insecure direct object reference" will stay at #4, or even rise to #3, until the Ruby-on-Rails project makes a change.
The fourth lesson is understanding "ease of use". Mass assignment makes creating websites a lot easier. But it makes securing websites much harder. You lose more in security than you gain in ease-of-use of the toolkit. As the GitHub hack showed, if you are putting your site on the Internet, security isn't an option. You don't need to fix every security problem, you don't even need to fix everything in the OWASP Top 10. But if you ignore the the top 4, you are a fool.
Finally, this shows the benefit of irresponsible disclosure. Homakov possibly broke the law, or at least, behaved "unethically" according to many people’s definition. Yet, it was not malicious, and caused no harm (other than deserved harm to reputation). It was the level of "disclosure" needed to bring what I feel is necessary attention to the problem.
(Update: AT&T has fixed this by the next day, as described at the bottom of this post.)
In 2010, a few grey hat hackers (like weev) were arrested for downloading information about new iPad users that ATT had provided freely on its website. All the hackers did was download what ATT freely published. But the reason the FBI arrested and prosecuted the hackers was simply because while ATT published its subscriber information to the entire world, they didn't intend for people to download the entire database. They intended instead for people to just see their own data.
Reddit is reporting that ATT is doing something like this again. This time, they allow anybody to lookup phone-numbers of their subscribers using only the subscribers e-mail address. Simply go to https://www.att.com/olam/enterEmailForgotId.myworld, enter in somebody's e-mail address, and if they are an ATT subscriber, you'll get their phone number. The first page looks like this:
When you hit "Next", you'll get a page that looks like this:
The purpose is obviously to help those who have forgotten some piece of their information. They clearly don't intended for anybody to abuse this feature. But they do nothing to stop abuse.
But it's so easy to abuse. As a hacker, it's trivially easy to take a command-line browser like curl to grab webpages, and to use a pattern search tool like grep to extract useful information. I've written a bash script 'getatt.sh' that does this. (This is just a modified version of the script from the Reddit comments):
When you run getatt.sh john.smith@example.com, it will output a line of text that looks like:
To make use of this, hackers would have to know your e-mail address. Or, they can find e-mail addresses in other places. For example, a million accounts of the YouPorn porn site were hacked recently, revealing people's e-mail addresses. A hacker could easily write a script that extracts each of those e-mail addresses and run it through the script above. It'll be slow, it's making a million webqueries against a slow site after all, but a hacker could start the script before going to bed, and wake up with a database of phone numbers of people who visit YouPorn. (The above script gives you a taste of the hacker mentality, but they'd do something better/faster).
Of course, if they ran such a script, ATT would complain to the FBI, which would then break down their door and haul away their computers. This is a sad thing: the law shouldn't protect cases like this were they freely publish information, but then arrest you if you download it.
Update: As I blogged about on the previous ATT incident, the flaw here isn't one of the OWASP Top 10 website flaws. The solution isn't to fix how they do this, but to stop doing this. The flaw is #0 on the OWASP list: sheer stupidity.
Update: ATT has fixed this. It now responds by emailing your phone number, and the page below telling you this:
In 2010, a few grey hat hackers (like weev) were arrested for downloading information about new iPad users that ATT had provided freely on its website. All the hackers did was download what ATT freely published. But the reason the FBI arrested and prosecuted the hackers was simply because while ATT published its subscriber information to the entire world, they didn't intend for people to download the entire database. They intended instead for people to just see their own data.
Reddit is reporting that ATT is doing something like this again. This time, they allow anybody to lookup phone-numbers of their subscribers using only the subscribers e-mail address. Simply go to https://www.att.com/olam/enterEmailForgotId.myworld, enter in somebody's e-mail address, and if they are an ATT subscriber, you'll get their phone number. The first page looks like this:
When you hit "Next", you'll get a page that looks like this:
The purpose is obviously to help those who have forgotten some piece of their information. They clearly don't intended for anybody to abuse this feature. But they do nothing to stop abuse.
But it's so easy to abuse. As a hacker, it's trivially easy to take a command-line browser like curl to grab webpages, and to use a pattern search tool like grep to extract useful information. I've written a bash script 'getatt.sh' that does this. (This is just a modified version of the script from the Reddit comments):
echo $1,`curl -d "customerEmailAddress=$1" "https://www.att.com/olam/submitSLIDEmailForgotIdSlid.myworld" -silent| grep -Po '(?<=provided \()\d*'`
When you run getatt.sh john.smith@example.com, it will output a line of text that looks like:
john.smith@example.com,6782345678To make use of this, hackers would have to know your e-mail address. Or, they can find e-mail addresses in other places. For example, a million accounts of the YouPorn porn site were hacked recently, revealing people's e-mail addresses. A hacker could easily write a script that extracts each of those e-mail addresses and run it through the script above. It'll be slow, it's making a million webqueries against a slow site after all, but a hacker could start the script before going to bed, and wake up with a database of phone numbers of people who visit YouPorn. (The above script gives you a taste of the hacker mentality, but they'd do something better/faster).
Of course, if they ran such a script, ATT would complain to the FBI, which would then break down their door and haul away their computers. This is a sad thing: the law shouldn't protect cases like this were they freely publish information, but then arrest you if you download it.
Update: As I blogged about on the previous ATT incident, the flaw here isn't one of the OWASP Top 10 website flaws. The solution isn't to fix how they do this, but to stop doing this. The flaw is #0 on the OWASP list: sheer stupidity.
Update: ATT has fixed this. It now responds by emailing your phone number, and the page below telling you this:
I want to respond to the following tweet, but in more than 140 characters:
Microsoft is a heavy user of IDApro. This one time, while giving a presentation at BlueHat (Microsoft's internal cybersec conference), while an IDApro image of Microsoft code was on the screen, I asked "How many of you use IDApro?". Hundreds of people rose their hands -- many more than when I ask the same question at BlackHat. It was a bit scary. I'll bet that Microsoft is buy far IDApro's largest customer, far larger than the CIA or NSA, or the entire US government.
They have to, out of self-defense. When they update their software, sometimes third-party code breaks. They have to reverse engineer that code in order to figure out what's going on, then create a workaround.
Back in the day, my code (BlackICE) broke when they tried to release WinXP SP2. That's because in order to provide a seamless installation without reboot, my code did evil rootkit-like tricks in order to patch the stack while under heavy network load, patching functions in the driver with an atomic jump instruction on multicpu systems. I think we might've even patented the technique.
They had to reverse engineer my code with IDApro to figure out what the heck I was doing, then changed their own code so that my code would stop breaking.
There are still people at Microsoft who hate me for this, who still complain about how evil my code was for delaying the release of SP2. The legacy of this is that in Windows 7, they checksum kernel code to prevent changes. This isn't simply to protect against evil hackers trying to install rootkits, it's also to protect against evil hackers like me creating legitimate software that gives Microsoft's headaches trying to support.
Some at Microsoft wanted to sue me, because in order to patch their kernel, I had to do "reverse engineering" on Microsoft's code. But here's the thing: it's impossible to write code for Windows without some "reverse engineering". Whenever your code breaks because of some undocumented behavior in an API, and you have to figure out why it breaks, you are essentially "reverse engineering" the code. The EULA refers to reverse-engineering-to-replicate, which is far different than reverse-engineering-to-interoperate.
But of course, in order to ship SP2, Microsoft had to break our EULA and reverse-engineer my code in return. Maybe I should've sued them.
So far, I've given 4 presentations at Microsoft (Bluehat or otherwise) where I've popped up live IDApro of their own code, protected against their EULA by, among other things, DMCA provisions supporting reverse-engineering.
Because of their legal hassles with anti-trust/monopolistic practices, Microsoft divisions are independent. They don't get access to each other's source code. In order to get things to work, each division has to reverse engineer the code of other divisions.
I doubt that Microsoft is using IDApro to do evil things, like reverse-engineer competitors to replicate stuff. Such secrets would be impossible to keep, and if they wanted to do such things, they'd work at arms-length with shell-companies and contractors in Asia. But for good things, like getting stuff to work, they use IDApro heavily. They have to reverse third-party drivers, and third-party applications, to see what changes in Windows break things. They have to reverse engineer other divisions, because they don't get access to source. Finally, the blog post the above tweet mentions is about malware research. Of course, Microsoft uses IDApro on viruses as well.
Update:All this predates IDApro. I remember back in the 1990s having casual conversations with Microsoft people about how we all reverse-engineered Diablo 2 (in our free time, not work related). For a lot of Microsoft people, reading binary is as natural as breathing.
comex In which Microsoft posts an IDA screenshot of their own code? RT@dragosr: goo.gl/RT8wD
Microsoft is a heavy user of IDApro. This one time, while giving a presentation at BlueHat (Microsoft's internal cybersec conference), while an IDApro image of Microsoft code was on the screen, I asked "How many of you use IDApro?". Hundreds of people rose their hands -- many more than when I ask the same question at BlackHat. It was a bit scary. I'll bet that Microsoft is buy far IDApro's largest customer, far larger than the CIA or NSA, or the entire US government.
They have to, out of self-defense. When they update their software, sometimes third-party code breaks. They have to reverse engineer that code in order to figure out what's going on, then create a workaround.
Back in the day, my code (BlackICE) broke when they tried to release WinXP SP2. That's because in order to provide a seamless installation without reboot, my code did evil rootkit-like tricks in order to patch the stack while under heavy network load, patching functions in the driver with an atomic jump instruction on multicpu systems. I think we might've even patented the technique.
They had to reverse engineer my code with IDApro to figure out what the heck I was doing, then changed their own code so that my code would stop breaking.
There are still people at Microsoft who hate me for this, who still complain about how evil my code was for delaying the release of SP2. The legacy of this is that in Windows 7, they checksum kernel code to prevent changes. This isn't simply to protect against evil hackers trying to install rootkits, it's also to protect against evil hackers like me creating legitimate software that gives Microsoft's headaches trying to support.
Some at Microsoft wanted to sue me, because in order to patch their kernel, I had to do "reverse engineering" on Microsoft's code. But here's the thing: it's impossible to write code for Windows without some "reverse engineering". Whenever your code breaks because of some undocumented behavior in an API, and you have to figure out why it breaks, you are essentially "reverse engineering" the code. The EULA refers to reverse-engineering-to-replicate, which is far different than reverse-engineering-to-interoperate.
But of course, in order to ship SP2, Microsoft had to break our EULA and reverse-engineer my code in return. Maybe I should've sued them.
So far, I've given 4 presentations at Microsoft (Bluehat or otherwise) where I've popped up live IDApro of their own code, protected against their EULA by, among other things, DMCA provisions supporting reverse-engineering.
Because of their legal hassles with anti-trust/monopolistic practices, Microsoft divisions are independent. They don't get access to each other's source code. In order to get things to work, each division has to reverse engineer the code of other divisions.
I doubt that Microsoft is using IDApro to do evil things, like reverse-engineer competitors to replicate stuff. Such secrets would be impossible to keep, and if they wanted to do such things, they'd work at arms-length with shell-companies and contractors in Asia. But for good things, like getting stuff to work, they use IDApro heavily. They have to reverse third-party drivers, and third-party applications, to see what changes in Windows break things. They have to reverse engineer other divisions, because they don't get access to source. Finally, the blog post the above tweet mentions is about malware research. Of course, Microsoft uses IDApro on viruses as well.
Update:All this predates IDApro. I remember back in the 1990s having casual conversations with Microsoft people about how we all reverse-engineered Diablo 2 (in our free time, not work related). For a lot of Microsoft people, reading binary is as natural as breathing.
The spikey nature of traffic comes from social-networking. People's Twitter and Facebook update several times a minute. When something gets posted at the top, it'll scroll off the bottom a few minutes later. When somebody with a lot of followers links to my blogpost, I'll see a spike of traffic for as long as it stays visible, with traffic decaying quickly as the tweet scrolls downward.
You can see that in the graph of traffic related to my previous blogpost on the hacker group known as "#Anonymous". I've labeled the graph as to the source of the various spikes.
Traffic started on Twitter has my the post traveled through my social circle. Then, Reddit picked up the post in the /r/netsec group. Then somebody posted it to StumbledUpon. Then came the weekend. That's always a low period for blogposts: people spend most of their time on social networking during work hours, but not at night or on weekends. Then Monday, the post picked up internationally. The source of those incoming hits were mostly from foreign language news sites, as well as a Russian and Spanish social networking sites.
Like most sites, I have social-media bar. Mine looks like the following image (not the real bar):
The numbers explode during the spikes. The Reddit counter updated mostly just during the Reddit spike. The StumbledUpon counter updated mostly just during the associated spike.
Here is the graph a day later. In this we see two more very sharp pulses.
These correspond to two Tweeets from @YourAnonNews, a Twitter account with half a million followers. The time of the peaks correspond precisely to the time of the tweets, and the incoming "Referer" link clearly identifies the URL shortener string used only by @YourAnonNews.
This says a lot about @YourAnonNews, that while they have 500,000 followers, that their followers only see the Tweets for a short window before they scroll away.
For comparison, here is graph of what the Slashdot effect used to look like, where it would take hours instead of minutes for traffic to decay:
Conclusion
This leads me to edit Andy Warhol's famous comment that "In the future, everyone will be world-wide famous for 15 minutes". In the future of social-media like Twitter and Facebook, you'll be world-wide famous, but for only 15 seconds. You may hit the Twitter feed of a million people, but in a blink of the eye, you'll disappear again.
 |
| This is what you'd see if the DNS blackout were successful |
But the attack is no longer practical. It's such a common idea that Wikipedia has a page devoted to it. For something so obvious, defenders have spent considerable time devising solutions. There are many reasons why such an attack won't cause a global blackout.
Reason #1: active response
Typical hacks work because it often takes a day for the victim to notice. Not so with critical Internet resources, like root DNS servers. Within minutes of something twitching, hundreds of Internet experts will converge to solve the problem.
We've seen this response in action after major Internet worms (Morris Worm, Slammer, Blaster) or undersea cable breaks destabilized the Internet. Despite devastating temporary effects on the Internet, defenders were able to react quickly and mitigate the problem, so that most people never noticed.
The easiest active response is to blackout the sources of the offending traffic. Defenders can quickly figure out where the attacks are coming from, and prevent packets from those sources from reaching the root DNS servers. Thus, people might see disruptions for a few minutes, but not likely any longer.
Reason #2: diversity
There are 13 root domain servers (labeled A through M), managed by different organizations, using different hardware, software, and policies. A technique that might take out 1 of them likely won't affect the other 12. To have a serious shot at taking out all 13, a hacker would have to test out attacks on each one. But, the owners of the systems would notice the effectiveness of the attacks, and start mitigating them before the coordinate attack against all 13 could be launched.
Reason #3: anycasting
Anycasting is a tweek to the Internet routing table so that traffic destined for an IP address is redirected to a different local server. Thus, while it may appear that the "K" root DNS server has only a single IP address "193.0.14.129", in fact there are 20 machines with that address spread throughout the world. When I trace the route to the "K" server from Comcast in Atlanta, it goes to a server located at an exchange point in Virginia. If you do your own traceroute, you are likely to find a different location for the server.
 |
| Physical location of the IP address 192.0.14.129 |
 |
| Route from Comcast in Atlanta to 192.0.14.129 |
Reason #4: fat pipes
The root servers are not located on the edges of the Internet, but are instead located at nexus points on the Internet backbone where many links come together. Even using the "network amplification" technique described by #Anonymous, it won't overload the network connections leading to the root servers.
Such attacks might overwhelm the servers themselves, but here amplification is much less of a threat. Whereas the raw "bits-per-second" is the primary limiting factor for Internet links, "packets-per-second" is the primary limiting factor for servers. The amplification technique results is bigger packers, but not more of them, so amplification affects servers less.
Reason #5: gTLD servers
All a root server does is resolve the last part of the name, like ".com" or ".jp". It then passes the result to the "gtld-servers". That means while the servers are designed for millions of requests per second, they practically only serve a few thousand per second.
Indeed, the best way to cause a "global blackout" wouldn't be to attack the root servers themselves, but the "gtld-servers" the next level down, or even the individual domain-specific servers (like those for Google or Facebook) at the next level. If people can't get to their Google, Twitter, and Facebook, the Internet is down as far as they are concerned.
 |
| All root server does is resolve the ".com" portion of "www.facebook.com" |
Reason #6: caching [update]
Your don't interact with the root DNS directly. Instead, you ask your Internet provider (Comcast, Verizon, AT&T, etc.) to do it for you. They don't need to repeatedly ask the same question to the root servers every time one of their customers clicks on "www.facebook.com". Instead, they can remember the response from the first lookup, then use that response for the rest of the customers who ask. This is called "caching" the response. The amount of time they cache the response, before redoing the lookup, is known as the "time-to-live" or "TTL".
The TTL for domains like ".com" is a couple days [edited]. That means, in theory, that the root servers could be down for a while before anybody would notice.
In their missive, the #Anonymous hackers claim that companies like Comcast ignore the TTL, and instead cache the response for things like ".com" for less than a day. I don't know. Regardless, it's a race against time: #Anonymous has to keep the root servers unavailable long enough for the major Internet providers to timeout their caches, while fighting the defenders who are racing to block the attacks and make the servers available again.
(I added this point in response to Michiel Klaver's comments below. I didn't include it in my original post because I haven't tested myself the veracity of #Anonymous's claims that Internet providers don't cache the root responses for a long time).
Consequence
The #Anonymous hackers can certain cause local pockets of disruption, but these disruptions are going to be localized to networks where their attack machines are located, or where their "reflectors" are located. They might affect a few of the root DNS servers, but it's unlikely they could take all of them down, at least for any period of time. On the day of their planned Global Blackout, it's doubtful many people would notice.
Note: just because I say #Anonymous can't do it doesn't it mean it can't be done. Rather than a "brute-force" attack flooding the target, searching for weaknesses is a better approach. I think I might be able to do it, given 6 months. There are others who know DNS better who could find a weakness in less time.
[update] When the root DNS servers do come under attack, you'll want to check out this page from Team Cymru monitors the health of the root DNS servers. They repeated query all the root servers from several locations around the Internet and measure how long it takes for their queries to be answered.
[update] Mr. Dan "DNS" Kaminsky has some good points at this Forbes article: Anonymous Plans To Take Down The Internet? We're Being Trolled.
[update] Mikko Hypponen points to this 2007 article: "There are not 13 root servers.
[update] IRC conversation about #OpGlobalBlackOut: http://pastebin.com/n71BkMPi
More than four years ago, the UN website was hacked via SQL injection. They haven't fixed their problem since then, which I've pointed out over and over and over. This last week, #Anonymous hacked them yet again using the same technique. If, after 4 years, the UN still can't protect their website, it's unlikely that they ever will.
But SQL injection is the easiest of all bugs to fix: simply stop treating data as code (use parameterized queries instead). The difference between the correct way, and the wrong way, is obvious and impossible to miss. Most hacker attacks are hard to understand, and hard to fix, but SQL injection isn't one of those.
So why, after 4 years, has the UN failed to fix the problem? Here are the possible reasons I can think of::
In my experience, it's usually #3: even though this is by far the most obvious and easiest problem to solve, most web programmers still aren't smart enough to fix it. Web site developers treat code as magic spells: they know which incantations work, but they don't understand how they work.
But SQL injection is the easiest of all bugs to fix: simply stop treating data as code (use parameterized queries instead). The difference between the correct way, and the wrong way, is obvious and impossible to miss. Most hacker attacks are hard to understand, and hard to fix, but SQL injection isn't one of those.
So why, after 4 years, has the UN failed to fix the problem? Here are the possible reasons I can think of::
#1. They don't want to fix it; they just don't care if their website is occasionally hacked.
#2. They don't understand the risk of treating data as code.
#3. Their programmers aren't smart enough to fix the problem.
#2. They don't understand the risk of treating data as code.
#3. Their programmers aren't smart enough to fix the problem.
In my experience, it's usually #3: even though this is by far the most obvious and easiest problem to solve, most web programmers still aren't smart enough to fix it. Web site developers treat code as magic spells: they know which incantations work, but they don't understand how they work.
This leads to problem #1: organizations find it easier dealing with getting hacked rather than fixing the underlying problem. This is especially true of an organization like the UN, whose managers are even less smart than their programmers, and who don't have the ability to fire incompetent programmers.
This further leads problem #2: because it's so hard getting your programmers to fix the problem, group-think leads to a state-of-denial, where the entire organization convinces themselves either that there is no risk, or that nobody can fix the problem.
So, next year, I'm going to write another blogpost entitled "UN's website still vulnerability after 5 years", still vulnerable to the easiest security problem on the Internet.
Update: By the way, I'm not insisting that they should fix the problem. Their site doesn't appear to have anything sensitive on it, so getting hacked is a small problem. Although, I suspect, if their programmers were more competent and able to fix it, that they would then want to fix it. Or, said another way, competent programmers would never allow SQL injection in the first place.
Update: If you are writing a large project in C/C++, it's very hard to verify that it has no "buffer-overflow" problem. But, if you are writing ASP+SQL code, it's trivially easy to verify that you have no "SQL injection" problems in the code. SQL injection really is the most obvious and easiest cybersec problem to solve.
 |
| The Sealand platform that was home to the data haven HavenCo. |
The infamous site Wikileaks is looking to move its operations to a boat in international waters! Holy shades of Snow Crash! The boat idea is being widely reported by several credible news organizations and repeated amongst social media network members today. The earliest incarnation of the story I can find puts Fox News as patient zero for this information spread.
I want to go on record with my opinion right now: I don’t believe it. To me buying a ship sounds more like a Hollywood plot than a anti-censorship strategy by a group of competent hackers for three reasons: it was an unnamed source, lawlessness of the open sea is a double edge sword, and nobody is that bad at disaster recovery planning.
Bad Journalism and Worst Ideas
My boss, Rob, often writes about FUD and security. Rob’s original Occupy Wall Street article is a shining example of his almost inhuman objectivity. After mentioning the possibility of Wikileaks going nautical he told me he didn’t believe it. The story is too sensational is his argument. Rob’s staunch anti-ship stance caused me to reread the stories. With the fresh eyes evaluating the story I have to agree with him. Citing unknown sources is shoddy journalism. Without sources this article is no better than schoolgirl gossip. Instead of Johnny likes Suzie we get Julian is fond of maritime law.
The premise of the boat strategy seems to rest on the belief that in international waters (about 12 miles off the coast of a country) Wikileaks avoids being subject to the laws of a target’s country. This belief is a fallacy. The "international waters immunity" myth is baffling to me. The myth seems to spring to life solely from people repeating it so often that it is assumed to be true. You cannot do what ever you want in international waters and get away with it. Since I am not a lawyer I will not engage in an ad-nauseam discussion of the semantics of law.
Being in international waters doesn’t mean you can do whatever you want; just what you care to defend against. This makes the 70% of the earth covered in water a briny version of prohibition era America: its legal if you can bribe or shoot your way out. If a backer has enough money to buy a boat large enough for use by Wikileaks then the fallacy of unlimited freedom would not come as a shock. I didn't see any articles discussing this point.
I can be a Commando or Just Hire Some
 |
| A sample of training I could use to take over a sea bound Wikileaks |
Once out in international waters the same freedom that the leakers seek could actually hurt them. After thinking about Wikileaks operating in international waters with a place like Sealand I thought about the easy access to military grade training that a few years ago was only for special forces high-speed teir-1 types. Take a look at this class from the firearms and training company, Magpul.
In this class I will learn how to employ a maritime assault force, non-compliant/opposed boarding, and hook and climb techniques. That’s all I need to board a craft and take the Wikileaks information by force.
 |
| Tagline for popular professional solider job website, Shooterjobs.com |
If I don’t want to take training the draw down of US forces Afghanistan and end of operations in Iraq means that there is a large number of paramilitary types that are available for hire. While jaunting off the deep blue sea sounds like a good idea at first the security concerns cannot be overlooked; you can face lawyers on land or mercenaries on the sea. Since one of the goals of Wikileaks was to stop wars it doesn’t seem that they would be very good at repelling a boarding party.
The example of mercenaries is reductio ad absurdum (thanks to Sheldon from The Big Bang Theory for adding that phrase to my vocabulary) on my part. The point is that you are trading one set of problems for a different set that Wikileaks is incapable of handling.
No Nines of Up-time, really
Lastly I just don’t think that a Wikileaks boat makes sense from a network availability standpoint. The boat would have to use a satellite link or some sort of line of sight connection for Internet connectivity. Both can be jammed. After Wikileaks spent time to have their site mirrored by supporters there is no sense in a move that would make silencing them a arms race of who has a bigger radio.
In order to be effective Wikileaks would need an armada, not a ship. Armadas are costly these days. The initial hardware costs are just the start of the problem the daily operations would exhaust the would-be digital pirates donation based budget instantly.
The biggest problem of Internet connectivity is where it terminates. What ever government is at the other end of the internet connection can disable it at any point and leave Wikileaks in no better shape than if they were in a more forgiving hosting location. In IT speak why would they inherit all this new risk to their new operations with very little reward.
Why it could Work
I will admit there is a scenario that would make the reports of a SS Leaker plausible: Bit Torrent. If the ship remained stealthy and only needed Internet connectivity to start the seeding of a new torrent based release there is some technical validity to the idea. The electronic face of the organization, the web servers and such, could be hosted anywhere as long as they weren’t holding any secrets. This would be like the Irish Republican Army splitting into public and guerrilla warfare halves so they could perform attacks then do press releases about it.
End Transmission
I am sure this idea was thought up in a chat room as a "what if…" scenario then was repeated enough until a reporter got hold of it. Set aside the coolness factor of being mistaken for a Bond villain and the purposed move to a ship really doesn’t make any sense for Wikileaks. They would be trading one type of trouble for another and would still need a way to provide reliable network connectivity. I don’t think risking Davey Jones’ locker is the answer, I think different leaders are. Since the Wikileaks fervor seems to have died down I guess any publicity will help the cause since starting a political party really hasn’t done Pirate Bay any good.
These are just my ideas; I have no insider knowledge on the alleged hoisting of anchor for Wikileaks.
[This was originally written on February 1st when the story broke, I just took two weeks getting it on the site. As far as I know aside from the initial story there hasn't been any additional information since I wrote this.]
People are excited that Intel is adding "transactional memory" aka "TSX" features in 2013. Ars Technica has an article here, but it feels like gobbledeegook to me. I'm not sure I can provide a less confusing description, but as a programmer who writes multicore code core, I think I can provide a different description.
It's not about making synchronization "easier" (as Ars Technica claims), but about making synchronization more "scalable". The problem with multicore code is that, after a point, adding more cores doesn't make the software any faster. That's because, after a point, the synchronization overhead needed by adding additional cores exceeds the additional processing power. This is known as "Amdahl's Law". A lot of multithreaded software can use 2, 3, or maybe 4 cores, but must software fails to scale to the 12 cores you get on a high-end Intel desktop.
Transactional memory reduces the cost of synchronization, and thus, makes software more scalable.
Average programmers won't use transactional memory themselves, but instead, it's the operating system, Java VMs, and assorted libraries that will use it. The programmers will just notice that their code now scales better.
An example of this is the code "atomic {x++; y++;}" on the Ars Technica article. That's precisely the sort of thing you can't do with TSX instructions. TSX transactions work on a 64 byte cache line. Thus, the above code snippet would only work if 'x' and 'y' were on the same cache line. These complicated details means it's unlikely to that high-level language constructs will matter. Instead, programmers will see low-level constructs, such as the current "intrinsics" used for SSE/AVX code that map from C/C++ to x86 assembly instructions. Programmers who write operating systems or libraries will use these instrinsics, but most programmers won't.
At a lower level, what these instructions really do is change how programmers use "spinlocks" and "wait-free algorithms".
A "spinlock" is when an additional number is used to synchronize access to memory. Before messing around with a chunk of data, code first changes the spinlock from '0' to '1', then messes around, then changes it back from '1' to '0'. If another thread comes along during this time, it notices that the spinlock is '1'. The other thread then "spins", repeatedly checking the spinlock value over and over again until it goes back to zero.
Notice that in some cases, the above logic wouldn't work. If two threads hit the start of this code at precisely the same time, both will see that the spinlock variable is '0', both will change it to '1' at the same time, and both will proceed, causing bad things to happen. Thus, this change is done in what's called an "atomic" operation. On the x86, this is done with a "lock cmpxchg" instruction. This locks out other processor cores from changing that value at the same time. In this scenario, one core will succeed in changing the value from '0' to '1', but the other core will fail, and know to start spinning.
The "wait-free" techniques take a different approach. Instead of using a single atomic instruction to synchronize access, they use a series of atomic instructions. This allows both threads to make forward progress, without forcing one thread to stop and wait for another.
Whether "spinlocks" or "wait-free" is better depends on a lot of factors. Wait-free is better from a theoretical point of view, but since atomic instructions are slow (30 clock cycles, or L3 cache speed), wait-free can be slower in practice.
So here's what TSX does. If you are thinking in terms of "spinlocks", it makes the code more efficient. Change your data so that it fits within a single cache-line, then write your "spinlock" as normal, but with a TSX extension ("xacquire lock cmpxchg", instead of "lock cmpxchg"). What happens is that, on older processors, the "xacquire" is ignored as a NOP (its value is 0xF2, which is meaningless to older processors in this context). On newer processors (2013 or later), the processor keeps track of what's really happening, and makes it more efficient. If two threads protected by that spinlock don't actually write into each other's data, then it's as if the spinlock didn't exist.
Better yet, if you are thinking in terms of "wait-free" code, you can do even more useful things. Wait-free code is written using something called "CAS2", or "double compare and swap". This compares two values simultaneously, and if both values match, swaps both to new values. This is often done swapping two pointers (to two new pointers), or a pointer plus integer. On 32-bit x86 this is the 'lock cmpxchg8b' instruction for swapping 8 bytes; on 64-bit x86 this is the 'lock cmpxchg16b' instruction, for swapping 16 bytes.
Because TSX operates on a cache line, which is 64 bytes wide, this effectively becomes a "lock cmpxchg64b" instruction, or CAS8. This makes wait-free code dramatically more efficient.
So the upshot is this. The problem is that software can only take advantage of a small number of processor cores before synchronization becomes too expensive. The new "transaction" features reduce the cost of synchronization, and hence, allows software to take advantage of more processing cores. There are two high-speed synchronization: spinlocks using a single atomic and wait, and wait-free that uses multiple atomics. In particular, it extends the old instruction that allowed 16 byte transactions (cmpxchg16b) to something that allows 64 byte transactions (think of it as "cmpxchg64b", but more efficient).
From the author of the Ars Technica piece:
@ErrataRob @comex Honestly, I read your blog post, and I don't think you've read Intel's docs.
No, I have read the Intel docs (the spec on two Intel blogposts). The difference is that that the Ars Technic posts just repeats them, going bottom-up, starting with the details. I'm trying to go top-down: starting with how people code today, and how the transactional features change that. For example, if you've every used the existing transactional feature "cmpxchg16b", you realize how much nicer life will be with these changes.
It's not about making synchronization "easier" (as Ars Technica claims), but about making synchronization more "scalable". The problem with multicore code is that, after a point, adding more cores doesn't make the software any faster. That's because, after a point, the synchronization overhead needed by adding additional cores exceeds the additional processing power. This is known as "Amdahl's Law". A lot of multithreaded software can use 2, 3, or maybe 4 cores, but must software fails to scale to the 12 cores you get on a high-end Intel desktop.
Transactional memory reduces the cost of synchronization, and thus, makes software more scalable.
Average programmers won't use transactional memory themselves, but instead, it's the operating system, Java VMs, and assorted libraries that will use it. The programmers will just notice that their code now scales better.
An example of this is the code "atomic {x++; y++;}" on the Ars Technica article. That's precisely the sort of thing you can't do with TSX instructions. TSX transactions work on a 64 byte cache line. Thus, the above code snippet would only work if 'x' and 'y' were on the same cache line. These complicated details means it's unlikely to that high-level language constructs will matter. Instead, programmers will see low-level constructs, such as the current "intrinsics" used for SSE/AVX code that map from C/C++ to x86 assembly instructions. Programmers who write operating systems or libraries will use these instrinsics, but most programmers won't.
At a lower level, what these instructions really do is change how programmers use "spinlocks" and "wait-free algorithms".
A "spinlock" is when an additional number is used to synchronize access to memory. Before messing around with a chunk of data, code first changes the spinlock from '0' to '1', then messes around, then changes it back from '1' to '0'. If another thread comes along during this time, it notices that the spinlock is '1'. The other thread then "spins", repeatedly checking the spinlock value over and over again until it goes back to zero.
Notice that in some cases, the above logic wouldn't work. If two threads hit the start of this code at precisely the same time, both will see that the spinlock variable is '0', both will change it to '1' at the same time, and both will proceed, causing bad things to happen. Thus, this change is done in what's called an "atomic" operation. On the x86, this is done with a "lock cmpxchg" instruction. This locks out other processor cores from changing that value at the same time. In this scenario, one core will succeed in changing the value from '0' to '1', but the other core will fail, and know to start spinning.
The "wait-free" techniques take a different approach. Instead of using a single atomic instruction to synchronize access, they use a series of atomic instructions. This allows both threads to make forward progress, without forcing one thread to stop and wait for another.
Whether "spinlocks" or "wait-free" is better depends on a lot of factors. Wait-free is better from a theoretical point of view, but since atomic instructions are slow (30 clock cycles, or L3 cache speed), wait-free can be slower in practice.
So here's what TSX does. If you are thinking in terms of "spinlocks", it makes the code more efficient. Change your data so that it fits within a single cache-line, then write your "spinlock" as normal, but with a TSX extension ("xacquire lock cmpxchg", instead of "lock cmpxchg"). What happens is that, on older processors, the "xacquire" is ignored as a NOP (its value is 0xF2, which is meaningless to older processors in this context). On newer processors (2013 or later), the processor keeps track of what's really happening, and makes it more efficient. If two threads protected by that spinlock don't actually write into each other's data, then it's as if the spinlock didn't exist.
Better yet, if you are thinking in terms of "wait-free" code, you can do even more useful things. Wait-free code is written using something called "CAS2", or "double compare and swap". This compares two values simultaneously, and if both values match, swaps both to new values. This is often done swapping two pointers (to two new pointers), or a pointer plus integer. On 32-bit x86 this is the 'lock cmpxchg8b' instruction for swapping 8 bytes; on 64-bit x86 this is the 'lock cmpxchg16b' instruction, for swapping 16 bytes.
Because TSX operates on a cache line, which is 64 bytes wide, this effectively becomes a "lock cmpxchg64b" instruction, or CAS8. This makes wait-free code dramatically more efficient.
Conclusion
So the upshot is this. The problem is that software can only take advantage of a small number of processor cores before synchronization becomes too expensive. The new "transaction" features reduce the cost of synchronization, and hence, allows software to take advantage of more processing cores. There are two high-speed synchronization: spinlocks using a single atomic and wait, and wait-free that uses multiple atomics. In particular, it extends the old instruction that allowed 16 byte transactions (cmpxchg16b) to something that allows 64 byte transactions (think of it as "cmpxchg64b", but more efficient).
From the author of the Ars Technica piece:
DrPizza Peter Bright
No, I have read the Intel docs (the spec on two Intel blogposts). The difference is that that the Ars Technic posts just repeats them, going bottom-up, starting with the details. I'm trying to go top-down: starting with how people code today, and how the transactional features change that. For example, if you've every used the existing transactional feature "cmpxchg16b", you realize how much nicer life will be with these changes.
Canada police arrest nearly 700 students CANADIAN police made nearly 700 arrests after mass protests by students in several cities on Wednesday night.
(heraldsun world)
Dirt Showdown review Dirt Showdown is a boisterous and varied racer best enjoyed with friends, writes Tom Hoggins.
(telegraph technology)
NASA time - lapse shows Lyrid meteor shower from space - as well as the Aurora Borealis and lightnin ISS astronauts captured a cameo appearance from the Lyrid metorite shower, as well as lightning and glare from city lights in Florida.
(dailymail sciencetech)
Ubuntu 12.04 LTS (Precise Pangolin) ready to install.