I think this might go down as the moment where Yahoo? lost their last shred of credibility as a technology company. And it's not this one mistake that signals the end...it's the fact that I'm not that surprised by it. If it were Google or even Facebook I would be shocked. But Yahoo? Yeah, sounds about right.
For a long time I've said that Yahoo? needs to forget the fact that they started as a search company. They're still a serious player in online display advertising and they own a lot of properties that are disproportionately valuable in terms of CPM. They should stop trying to come up with new doohickies and focus on what they do best - selling targeted advertising to major advertisers.
It's a shame that they didn't hit the goldmine like google or fb did, but there's no point in letting the past get in the way of the opportunities of the moment. Yahoo could still be one hell of an ad network.
I have to agree with you. They have lost all cred as a tech company and have been circling the toilet for a while.
Sadly, I think this has a lot to do with management and very little to do with engineers. I personally feel they are just sitting comfortable trying to squeeze every dollar out of the company.
Yahoo! released Axis (with this very dumb mistake) at 5pm PST, and by 9pm PST their public key is posted, with a "I report this but have yet to hear back" note. How, exactly, is this responsible disclosure?
I always, always, always go the route of contacting vendors - over the past 15 years I have reported hundreds of security and privacy vulnerabilities. This is the first time where I haven't reported to the vendor first before disclosing.
The way this came about was a bit different, because it started with a tweet[1] where I pointed out that the file was there, and then it gradually developed into realizing that it is a pretty big deal. The discovery happen out in the open. If you look at my timeline and the replies and conversations you will see how it came about.
With hindsight I could have handled it differently, but it just happen to come out in this way. I added an update to the end of the post addressing disclosure. The goal at the moment is to make users aware that there is potentially a big issue here.
There was zero (0) chance this wasn't going to get found 100 times independently whether or not you publicized it. Getting it out quick and loudly was absolutely the right move. You have nothing at all to apologize for.
thanks. and you are right, at least two other people found the same thing, then searched twitter and found my post about it. one of them was @rasmus the creator of PHP (pretty funny timeline of him discovering and then finding on twitter).
It's your bug, finders keepers. I always despair when I hear people talk about 'responsible disclosure', as it's a term so often used by vendors to keep finders quiet. By disclosing it at all you've highlighted the issue and Yahoo have rightly moved to fix it quickly. So I can sign a chrome extension with a valid cert for maybe a day, it's not the end of the world.
Responsible disclosure exists in order to allow an obscure, previously undiscovered bug to be patched before others know about it. The idea is that no one else is likely to discover the issue while it is repaired.
This is not an obscure bug. This is obvious -- very obvious. Many people will have discovered this already. Furthermore this is a pre-release product.
There is nothing to be gained by not talking about it.
Whether or not the disclosure is responsible is irrelevant. What's irresponsible is uploading Yahoo's private signing key to the Internet. The author of this article is just warning others so they can uninstall the extension before someone uploads malware and Chrome auto-updates it.
Considering that in this case the "public end users" are the ones who are most at risk due to this vulnerability, I think its fair game that this be a public disclosure. i.e. people should delete this browser add on (and anything signable with the same key) as its been compromised.
its a private key btw. wouldn't be any issue if it was a public key.
its not responsible disclosure but then again, everyone could see the key after an hour. it's not like if it was a complex exploit. Its more like if you printed the password to your stuff on a document and told the world to grab a copy. ;-)
Is a brand new thing with no userbase. Seems an extremely responsible time to disclose this.
As I understand it, responsible disclosure is primarily there to protect the userbase of a piece of software, not the reputation of the producer of that software.
And surely they can't be being stupid enough to be using this same signing key on established products, can they?
The question isn't so much what other things Yahoo! might be using this signing key for, it's what other things bad guys might be able to sign with it.
I'm asking because, one day, someone here will leak the wrong key. I already have enough problems with legal on opensourcing our software (we built a very cool CMS that runs on Node.js and MongoDB we'd love to share) and I may need to come up with some creative answer fast.
Google blacklisted the cert within a few hours, which removed the extension. I installed Axis last night, and this morning I noticed it had disappeared from Chrome. So I just need to reinstall it, which will be signed with the new cert.
Hopefully we'll get a full write-up so anyone else this happens to in the future will know what to do.
>Why would you say that? It works well enough here.
Well, both projects are rather new and changing. So not a very stable base to base a business on.
Node.js is best suited for long-running, evented type web apps (games, chat, interaction etc), so a CMS would not be a good fit.
Mongo is also known to lose data, and needs several (3 at least) servers to be somewhat stable with this.
A CMS is also not particularly read or write heavy, so a standard DB would fit even better.
I assume the data already have some specific form, so the free-form (schema-less) of Mongo doesn't buy much (and you have to replicate some relational-es on top of Mongo anyway, if you want to avoid inefficient queries returning tons of unneeded data with the response that happen to be on the same level in the "tree").
In a CMS you also have a power-law distribution of read articles, or even worse, with the top page stuff getting the most hits, and older pages being statistical noise. So some caching should provide very good speed with very little memory needs.
(Funny aside/rant: once I've implemented a custom CMS for a large bank in my country, with plain ole Java and DB2. The bank people had fallen for some IBM crap, and wanted the backend to be Domino, which, at the time (2003) was, well, let's say, inadequate. Our team implemented a CMS on top of Domino, and, as it naturally was slow as molasses, I convinced them to let us rewrite it in a sane way, which I did by myself in 1/5 the time it took to build the BS Domino version (about 2-3 months). It even had fancy things like being able to have them just upload an Excel file and automatically populating currency rates and stuff from it, with proper Decimal support, fail-rollback, etc). Hah, I also used Lucene for FTS, which was at version < 1.2 at the time IIRC.
> Well, both projects are rather new and changing. So not a very stable base to base a business on.
The CMS is also evolving fast. We are a web portal with a strong news side.
> Node.js is best suited for long-running, evented type web apps
This evented nature is handy when more than one person is editing a top page. It started, in fact, as an add-on to our previous CMS (the absolutely awful FatWire) that made it possible to quickly modify those.
> Mongo is also known to lose data
Most of the time, the CMS keeps a copy of the data in memory and spits it to the datastore. Making it DB-agnostic is on the roadmap.
> I assume the data already have some specific form
Not at all. One of the worst sins of any CMS is to constrain the structure of a given document.
> if you want to avoid inefficient queries returning tons of unneeded data
The CMS is not responsible for most of the content-delivery. Most page elements that rely on queries against the article base do so in efficient ways (the content has some structure - but only what's needed). We consider a problem when a page view triggers a DB lookup. We also keep an eye on returned vs. used rates.
If the Paranoids or PR found out you're commenting publicly about this and portraying yourself as an official representative, they'd have your ass. Be careful.
And I've been around twice as long as you! I also understand the reasons for the humor taboo.
But there's a sadness about the Yahoo situation that invites joking as a coping mechanism. If we don't laugh, we'll have to cry. Or rant.
And speaking of rants: plenty of upvoted, 'serious' comments about this incident are just variants of "HUH-hah, look at Yahoo's latest screwup!" Those can be even worse for reasoned discourse than a few silly quips in one tangent. But HN smiles upon the hyper-critical and mock-aghast sort of rhetorical competition.
When you click the period it actually launches a black helicopter.
It isn't actually meant to do this, but the guy who wrote the code left a while back and nobody knows how to fix it, or even where the helicopters are being sent. However there are unconfirmed reports of an interesting pile of scrap metal growing at the bottom of Jerry Yang's garden.
The most surprising part of this is that there's an established security audit process for any product before it gets launched to the public. Somehow this made it though.
From my experience having worked at Yahoo! I'm a bit shocked as the process has always seemed pretty good.
I installed the Chrome extension (direct link to original Chrome extension, probably not a good idea to install it) with the idea of checking out the source code.
You don't need to install chrome extensions to look at their source, you can use this extension to view it before installing:
This is not a security flaw in Axis, this is a leaked trusted key that could be used to sign any extension (or possibly any other type of signed code). Any code purporting to come from Yahoo is unsafe, probably until Chrome is updated.
Surely Chrome implements a cert revocation mechanism; the idea of using a cert to establish identity really doesn't work without it (for precisely this reason). Anyone have details?
I wasn't sure it if it was reliable. I remember during the last "ca leaks root cert" fiasco there was talk about how browsers don't implement this securely.
Right, but that's different. That was a root certificate that was compromised: something you can use to make new certs. The basic certs themselves can be revoked, and are fairly routinely.
There is always a root of trust in a cert scheme (vs. a web scheme, say, which has no single point of failure but a squishier notion of validity). The reason it got caught is that Chrome implemented an independent "pinning" feature for Google's own domains (basically an independent root of trust) and caught the fraudulent certs.
The browser is the new toolbar. In case you haven't seen it, IE7Pro added some major features to IE. Some toolbars even added `data:` schema support to IE.
Want to see the cool Moog doodle? Download the latest HTML5™ toolbar today! Want to use premium Yahoo features? Download the Axis toolbar!
Out of protest, I downgraded to NCSA Mosaic and tied an onion to my belt, which was the style at the time. Not many web pages loaded correctly, but the important thing was that I had an onion on my belt, which was the style at the time.
I managed to get Mosaic to compile on OS X, interestingly enough some pages do still load and look OK. One was Dennis Ritchie's page: http://cm.bell-labs.com/who/dmr/
It was actually really easy. It's not much of a surprise if you think about it. Most of the libraries Mosaic was built on ended up becoming standard, so you can just go download the old versions, compile them and link. (think libpng, Motif, etc...)
If people were interested enough I could write a quick walkthrough of what is needed though since some of it wasn't intuitive :)
edit: probably a lot easier to just get it on github https://github.com/alandipert/ncsa-mosaic -- possibly not nearly as fun. Make linux probably won't work on Mac OS X (almost), I recall having to force the compiler to create a 32 bit executable and some other things.
Now, my story begins in 19-dickety-two. We had to say "dickety" 'cause that Kaiser had stolen our word "twenty". I chased that rascal to get it back, but gave up after dickety-six miles.
Probably the obvious fix is for them to change the auto update path to https rather than http on a subsequent update. Are there any good reasons why this wouldn't have been done in the first place?
Where is the signature from this key used? I don't see any signatures or certificates in the crx archive (just the key), and I'm curious as to the trust path here - or is this an internal-to-Google's-extension-site key?
The signature it generates is used by Chrome to determine whether an upgraded extension really came from the same source. With this leaked, anybody could conceivably put up an upgraded, evil version of Axis and Chrome would happily upgrade it behind the scenes. I say conceivably because you still need to either MitM the Chrome store or get Yahoo!'s credentials to the store.
For a long time I've said that Yahoo? needs to forget the fact that they started as a search company. They're still a serious player in online display advertising and they own a lot of properties that are disproportionately valuable in terms of CPM. They should stop trying to come up with new doohickies and focus on what they do best - selling targeted advertising to major advertisers.
It's a shame that they didn't hit the goldmine like google or fb did, but there's no point in letting the past get in the way of the opportunities of the moment. Yahoo could still be one hell of an ad network.