Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Apple Watch Still Waiting On App Developers 213 213

An anonymous reader writes: It's been almost three months since the Apple Watch launched, and the tiny device hasn't taken people's wrists by storm. That's not to say it's a failure — experts estimate Apple has sold between three and five million of them, and we may get more detailed sales information during their earnings call, tomorrow. But many major app developers are still missing from the Watch's catalog, and Apple doesn't have a good way of roping them into the new section of its ecosystem. "I don't know if we could get it all in there in a way that feels good and works well," said a Facebook executive. "Why would you look at a small picture when you can look at a large one on your phone?" said Snapchat's CEO. The app rush that hit phones and tablets is dampened for the Watch. For now, all Apple can do is improve their development toolkit and hope coders can figure out useful new wrist-based interactions.

Comment Re:Fuck McAfee (Score 1) 75 75

The "crown jewel" of McAfee is ePO -- "ePolicy Orchestrator". Basically centralized management for your AV deployment (and will even managed SYMC AV), as well as any other McAfee product, and a host of 3rd party security products that have integrated into the ecosystem.

It STILL dominates the enterprise market, no matter how crap McAfee AV is.

Comment Re:Fuck McAfee (Score 3, Informative) 75 75

My (somewhat informed, but could still be wrong) guess as to what Intel was thinking at the time (remembering that this was about 5 years ago):

Intel had made a big investment in enterprise chipsets with features like VT and AMT. They were hoping to speed up enterprise hardware refresh rates for a decade or so by continuing to provide highly compelling enterprise features in hardware.

One area they thought held particular promise was security. They were interested in AV companies leveraging a combination of VT and AMT to provide a more secure environment-- basically they wanted to see host-based security technology live outside the end-user's OS, but still reach in to detect and protect. That way, if a box did get popped, you could still update signatures, etc and have some reasonable hope that you could actually repair the OS without wiping it. Lots of other little bits in the vision.

The big problem for Intel was that they needed security vendors to build and sell software on top of this platform. But it was a bit of a "chicken and egg" problem, where there wasn't enough of a hardware footprint to justify a product investment, and so there wasn't enough compelling reason for people to pay extra for the hardware.

Intel pushed most A/V companies hard for some investment in the area, and McAfee actually did peel off a SMALL team to work on it (quite possibly the best engineering team w/in McAfee actually). They spent maybe a year making some good progress, and then when DeWalt was trimming down to save costs, that team got cut.

I'd heard that Intel was enraged. I can imagine them thinking they needed to control their own destiny-- get the security software built that they thought would drive faster hardware refreshes. McAfee had been the most amenable, and was definitely primping itself to be acquired.

By the way, McAfee does NOT own PGP. They'd spun it back out, and it got re-acquired by Symantec.

The Courts

The Ongoing Case of Rakofsky vs. Internet 157 157

Chmcginn writes "Joseph Rakofsky, a New Jersey lawyer whose claim to internet fame is filing a lawsuit against the Washington Post and the American Bar Association for criticizing his performance at a Washington, DC murder trial, has amended his suit to include a number of bloggers and internet forum members — for criticizing the lawsuit. Which is a bigger threat to free speech — direct government action, or fear of lawsuits for frivolous defamation charges?"
It's funny.  Laugh.

Newsweek Easter Egg Reports Zombie Invasion 93 93

danielkennedy74 writes " becomes the latest in a long list of sites that will reveal an Easter egg if you enter the Konami code correctly (up, up, down, down, left, right, left, right, b, a, enter). This is a cheat code that appeared in many of Konami's video games, starting around 1986 — my favorite places to use it were Contra and Life Force, 30 lives FTW. The Easter egg was probably included by a developer unbeknownst to the Newsweek powers that be. It's reminiscent of an incident that happened at ESPN last year, involving unicorns."

How Nintendo's Mario Got His Name 103 103

harrymcc writes "In 1981, tiny Nintendo of America was getting ready to release Donkey Kong. When the company's landlord, Mario Segale, demanded back rent, Nintendo staffers named the game's barrel-jumping protagonist after him. Almost thirty years later, neither Nintendo — which continues to crank out Mario games — nor Segale — now a wealthy, secretive Washington State real estate developer — like to talk about how one of video games' iconic characters got his name and Italian heritage. Technologizer's Benj Edwards has researched the story for years and provides the most detailed account to date."
Input Devices

Brain-Control Gaming Headset Launching Dec. 21 112 112

An anonymous reader writes "Controlling computers with our minds may sound like science fiction, but one Australian company claims to be able to let you do just that. The Emotiv device has been garnering attention at trade shows and conferences for several years, and now the company says it is set to launch the Emotiv EPOC headset on December 21. PC Authority spoke to co-founder Nam Do about the Emotiv technology and its potential as a mainstream gaming interface." One wonders what kind of adoption they expect with a $299 price tag.

Comment Thanks! (Score 5, Interesting) 216 216

Ben, Thanks for the positive review. I know the book has pissed some people off, especially when I take on their particular sacred cows (e.g., intrusion detection). But, the Schneier chapter isn't meant to piss him off, I have no beef with him whatsoever. I just think the fanboys do the world a disservice by not thinking for themselves, especially when they draw from material that's a decade old. John

Major Spike in Security Threats To Online Games 48 48

Gamasutra reports on data from security software firm ESET, which shows a major increase in the number of gaming-related security threats over the last year. They attribute the rise in attacks to the amount of money involved in the games industry these days. ESET's full report (PDF) is also available. "[ESET's research director, Jeff Debrosse] explains: 'It's a two-phase attack. If someone's account was compromised, then someone else can actually [using their avatar] during a chat session, or through in-game communication... they could leverage that people trust this person and point them at various URLs, and those URLs will either have drive-by malware or a specific [malware] executable. What ends up happening is that folks may end up downloading and using it. This is just one methodology.' These attackers also target gamers in external community sites, says Debrosse, through 'banners on websites or URLs in chat rooms or forums' — which can lead to unsafe URLs. 'If [users] don't have adequate protection, they could very well be downloading malware without their knowledge.'"

Here Comes iPhone Nano, But Not In the US 177 177

jehovajerieh writes to us in the time-honored tradition of rampant Apple speculation, pointing to an article over on IBTimes suggesting that while the iPhone Nano may be on the way, the US might not be the first to experience this gadget bliss. "Despite limited information in the supplier channels and typical secrecy with new Apple products, insiders have confirmed that the iPhone nano is not yet in the testing labs at AT&T, Marshal says, leading him to believe that the launch will most likely be with a non-US carrier. 'Obviously, the best-case scenario here would be a China launch (~600mil+ wireless subscribers total in the country), but we have no definitive knowledge of this and are working on identifying the [locale] of launch and other pertinent details,' he said."

Comment Re:The sky is not falling. (Score 1) 300 300

For most people, this will put them at MORE risk than selectively blacklisting rogue certs as they are identified:
  1. It is very likely that no bad guys will ever get a chance to use this attack. For them to use the next MD5 attack they would need to be able to predict a sequence number several months in advance, instead of several days.
  2. Any attack of this type will be pretty obvious from the CA's logs. CAs that sign with MD5 will need to invest some man power in manual validation, but this is not a huge cost. This is how you find the unknown certs, if there are any (which is highly likely).
  3. Since many legitimate web sites use SSL/TLS certs from RapidSSL, taking your advice for remediation will just give them pop-ups on some legitimate sites, which is likely to desensitize them. When people get enough pop-ups for stuff that isn't a risk, it's well known that they start just clicking through, so this would put the average person more at risk.

Comment Re:The sky is not falling. (Score 1) 300 300

The relative security between MD5 and SHA1 is currently more or less linear to the digest size, though more work has been done on practical applications on MD5, so it is a little weaker relatively. For cases where the birthday paradox applies, you lose 1/2 your bit length in the brute force case.

Comment Re:The sky is not falling. (Score 1) 300 300

There's some confusion here. I'll try to clear it up. Let's imagine that you've got FredCA that got its CA credentials from Verisign. Let's say FredCA is perfectly legitimate. That means that they have a cert with a signature on it from Verisign. Let's say that Citibank wants to get a leigitimate certificate and they go to FredCA. The certificate they get back is signed by FredCA.

When your browser goes to Citibank, it gets to see the entire certificate chain (the server sends back a PKCS blob of the entire chain). It validates not only that the Citibank cert was signed by FredCA, but it also validates the signature on FredCA's certificate. If it trusts Verisign, then it makes sure that the certificate is definitely one it knows maps to verisign, and then everything is trusted.

A lot of people here seem to believe that the attack is that a bad guy can take the cert that FredCA endorsed for CitiBank or the cert that Verisign endorsed for FredCA (as long as the signature uses MD5), and steal the signature for their own certificate. If that were true, then we could not trust any certificate signed by MD5. Good thing that most certs have been issued via SHA1 for a while.

But, that is not true. In this attack, the bad guy can generate a pair of certificates, one that the CA signs, and another for which the same signature happens to be valid. You cannot do this to any cert on the internet, the pair of certificates have to be specially crafted.

In this attack, the bad guy gets FredCA to sign a certificate for DummyOrg, but when the bad guy created the DummyOrg cert, he created a matching cert for his own CA, call it EvilCA. Since the certs were created together in a particular way, the bad guy can take the signature off the DummyOrg cert and paste it onto the EvilCA cert and everything will work.

With the EvilCA cert, he can create certificates that claim to be from any site on the internet, even though they are not. When they get to the browser, the browser looks at the whole chain, and it looks good, even though FredCA never signed the EvilCA certificate. However, once we blacklist the signature for the DummyOrg cert, we will immediately blacklist everything endorsed by EvilCA, because when a browser goes to validate the whole chain, they'll see that the certs are issued by a blacklisted CA, and thus would know that the certificate is fake.

Also, note that there's a good reason to believe this hole will be closed well before any bad guys actually try the attack. At most, the world will have to blacklist a small handful of rogue CA certs.

Additionally, for the CAs other than RapidSSL, it's not clear they can be attacked easily. As far as I know, they all usually sign with SHA1. I don't know how you would get them to choose MD5, but I suspect none of them will do it anymore after this. And, even if they did, you would need to know how to predict their sequence number and the date values they add to the certificate. With RapidSSL that was all automated and very predictable. It could be with the other CAs, but it isn't necessarily the case.

Hope this helps.

Comment Re:The sky is not falling. (Score 1) 300 300

I think you either didn't read my writeup at all, or didn't understand it. But, I most certainly got it right. Ask any other cryptographer out there. Or, just read the researchers write-up carefully. It is very clear.

From what I understand from your posts, you're saying I don't need to create two certs with the same hash, I "just" need to create a new cert that matches an existing web site's cert. That's not true, and some intuition should demonstrate it. If you understand the birthday paradox, it says that, with brute force for MD5 (that is, if we assume MD5 is perfect), my explanation (remember, brute force), would be O(2^64) to attack. Yours would be O(2^128). Now, if someone has tricks to do better than brute force, perhaps they'd work in your context but not mine, or vice versa. Or, more likely, any structural weaknesses in MD5 are likely to have implications for both kinds of attack. Now, since O(2^64) was already near the border of feasibility, while O(2^128) was very far from it, which kind of attack was likely to become more practical first?

The whole point of my post on O'Reilly was that people do seem to think the research in question represents the scenario you're talking about. If that were the case, we would indeed have to quickly stop allowing even legacy MD5 certificates, which would be a little painful. But, that is absolutely not the case. If the few risky CAs deal with the problem quickly, this will be a huge non-event.

A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt