Hacker News Reader

> Mayvethat's actually a reason BSD was contracted late, maybe they expected interested scrutiny from the other BSD projects from any kernel patches. Linux certainly ended up exhibiting that behavior, maybe they were worried about it there too but Linux's size meant a different call was made?

FreeBSD is a serious project which takes security embargoes seriously, they don't break embargoes: http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-...

> Not as a defense of Google, but what's so wrong about Google not contacting FreeBSD? It's obvious that not all operating system vendors could be contacted (should they be contacting small hobbyist operating system projects? What about small niche commercial ones?), so choices of who to contact and when had to be made.

> I understand why BSD devs are upset, but the complaining comes across as exactly what it is, whining they didn't get treated like the big boys. It sucks. Linux used to be right there with you, and neither got any special treatment, but times have changed.

Not notifying the FreeBSD devs is bad for the entire internet. The Netflix open connect CDN is FreeBSD and pushes 37% of North American downstream traffic[1]. Limelight one of the big CDN providers use FreeBSD for it's edge network[2]. Some of the DNS servers for .com and .net are FreeBSD[3] Juniper routers run FreeBSD[4] PS4s run a modified FreeBSD[5], the Apache foundation runs a lot of there infrastructure on FreeBSD[6]. Whatsapp with it's billion plus users run on FreeBSD servers[7].

None of those things should be vulnerable to known bugs if we want a safer internet. So notifying the FreeBSD devs 6 months late did the entire internet a disservice regardless if you use FreeBSD directly or not.

[1] http://appleinsider.com/articles/16/01/20/netflix-boasts-37-...

[2] https://www.freebsdfoundation.org/testimonial/limelight-netw...

[3] https://www.freebsdfoundation.org/testimonial/verisign/

[4] https://www.juniper.net/documentation/en_US/junos/topics/con...

[5] https://www.theregister.co.uk/2013/11/16/sony_playstation_4_...

[6] https://www.freebsdfoundation.org/testimonial/the-apache-sof...

[7] https://www.freebsdfoundation.org/testimonial/whatsapp/

You know what almost all those examples have in common? They don't generally run user code, so are very unlikely to be running non-vetted code. I wouldn't be surprised if the majority of them don't bother with the fix because of the low chance of being affected and potential performance cost.

When it comes to operating systems that have a large base of users and may run unvetted code, the big candidates for that are operating systems that have home users downloading and running software or in the browser, and shared environments such as shell servers, shared hosting providers and virtual services providers. FreeBSD's common industry use cases and low end-user use mean it's much less exposed to this particular problem.

Edit: grammar, typoo and clarity fixes.

In this particular case, I agree, but it does suggest there should be a workflow for notifying the FreeBSD team of bugs, and I don't see what harm using it here would have caused.

I think the harm is in increasing the parties that have to know about and conform to the embargo.

If FreeBSD should be notified in this case, even though they aren't really in most of the high impact areas, should OpenBSD be notified? What about QNX? What about OpenSolaris? Apparently Joyent got late notification as well[1], and since they actually are a cloud provider, I think they have a much better case for being notified before FreeBSD.

In the end, if there's an information embargo there needs to be a decision about who's in and who's out, and most times there will be some excluded party that really wishes they were included. You can't make everyone happy, but I don't think FreeBSD really needed a huge advance warning, given what it looks like Google's criteria was for notification. The fact the hyperthreading bug that keeps being referenced was handled differently seems to me to be mostly an artifact of a BSD developer finding the bug.

1: https://help.joyent.com/hc/en-us/articles/115015938847-Secur...

That's correct -- we at Joyent had no advanced disclosure. That we have our own operating system (SmartOS) that also serves as the hypervisor in our own public cloud (and that Intel knew and knows all of this) really did/does leave us in a uniquely terrible position. While we have made excellent progress on KIPT for SmartOS/illumos, it is also true that this is very delicate work in the core of the system; that we are forced to do this while vulnerable belies any notion that this was responsible disclosure.

Ah, that's unfortunate. From a little research, the wording from Linode's announcement makes it sounds like they didn't get advance warning, but the wording from Digital Ocean's announcement sounds like they had a few days. I'm not sure how it all worked out, but I agree you guys are a specific case where at least little advance warning would have helped quite a bit, since you can't piggyback on the community nearly as much. Linux providers can at worst just wait for kernel patches and then roll them into production.

> I think the harm is in increasing the parties that have to know about and conform to the embargo.

FreeBSD has conformed to embargoes in the past, telling them would not harm the embargo.

> but I don't think FreeBSD really needed a huge advance warning, given what it looks like Google's criteria was for notification.

You have source for their criteria?

> FreeBSD has conformed to embargoes in the past, telling them would not harm the embargo.

So? Should they be notified of Microsoft windows vulnerabilities just because they've shown they can handle themselves? There has to be a cutoff somewhere. I don't think FreeBSD was in the highly affected subset of use cases. I can imagine others coming to the same conclusion.

> You have source for their criteria?

No, that's what "looks like" in my comment is there for, to imply it's an assumption on my part. They notified chip makers, the large end user OS makers, and many/most the major cloud providers (this probably depends on what you consider major, I don't know if Linode or Digital Ocean were notified, but AWS was, and Joyent wasn't..), which are what I would think the highest impact areas are, as those use cases either require running third party code or often due so (end users and downloaded software or browsers with JS).

To me, that appears like they tried to get the most major players most affected some info.

> So? Should they be notified of Microsoft windows vulnerabilities just because they've shown they can handle themselves? There has to be a cutoff somewhere. I don't think FreeBSD was in the highly affected subset of use cases. I can imagine others coming to the same conclusion.

Seriously what the hell are you talking about? I was saying FreeBSD should be notified of security bugs that effect FreeBSD and not 6 months after other Operating systems are told. I said nothing of Microsoft.

Look at it this way, what's the common case that a FreeBSD install could fall victim to this? Are people commonly running untrusted binaries on those desktops or servers? Is FreeBSD used for a large amount of shared hosting platforms (larger than Linode/Digital Ocean)?

Of those cases where it is more susceptible, what percentage of the overall likely susceptible hosts does that account for? Do you think it's even 0.1%? Even 0.01%?

If that's the case, and I was Google, I'd be just as likely to notify FreeBSD about this when attempting an embargo as some random MS vulnerability.

Your seriously overthinking this. It's as simple as FreeBSD is used extensively across the world, not as much as Linux or Windows, but still millions of servers and appliances run FreeBSD. The next detail relevant is whether FreeBSD devs honor embargoes, which they do. Everything else you have written is just trying to rationalize a bad decision by Google and company.

You act as though they don't run code exposed to the internet that could be used to leverage this privilege escalation. Talk about short sighted...

It would have been all well and good if at the same time announcement was released a new linux mainline build with the mitigations would have been available. It has not been. Only Google's systems got the patches all the way back to September.

I'm not at all anti Google saying "We are Google. If you pay us to run your systems you would be protected. If you do not, then eff you, we don't care". I'm anti-fluffy "Google is awesome and does things for the community" garbage popular in tech circles, HN included.

Google found these vulnerabilities in the first place, and many serious ones before Spectre/Meltdown too. We don't know if state or other actors found them first, but we know that if Google was not in fact "doing things for the community" here by finding and disclosing them, they'd still be unknown to us, and there would be no mitigations at all. To rubbish all of that defacto contribution, because they didn't disclose it the way you might prefer, is asinine - talk about looking a gift horse in the mouth!

All you're really doing here is confirming that you are typical of the HN userbase these days (far past its prime and filled with reactionary tinfoil hat types with a raging hate-on against one company or another) - that Google is on your personal shit list, and that you'll characterize just about anything positive about them as "fluffy garbage". And that's just not very interesting - it's tiresome, practically-writes-itself noise to everyone other than the choir you are preaching to.

> we know that if Google was not in fact "doing things for the community" here by finding and disclosing them, they'd still be unknown to us, and there would be no mitigations at all.

Not only is that a hypothetical what-if scenario that you've invented whole-cloth to support your argument, it's provably false since there was parallel discovery from three other teams at approximately the same time.

https://www.wired.com/story/meltdown-spectre-bug-collision-i...

Not at all. I'm using google products and I'm paying for Google products with real $$$, not fluffy feelings. I also use products of Microsoft, and I pay for products of Microsoft with real $$$, not fluffy feelings.

I am prefectly OK with Google and Microsoft's position being "Eff you, we only support our customers and those who are not our customers can become our customers so we can support them".

The general view on HN for some reason is that Google this benevolent do gooder. That's the view that needs to be dispatched. Google is a standard company. It happened to be quite big and have quite a big market. To defend its market it needs to be involved in security research. For lots of reasons, of which I would say PR is one of the most important, it also cannot afford to sit on the vulnerabilities that it discovers forever as someone else may discover them independently ( think Chinese competitors of Google ) and may use them against Google's interests in a way it cannot currently identify.

HN user base gets lots of Googler who are pretty fanatical about the company -- which I guess is understandable as without Google they may not be able to support their lifestyle.

You realize there are several fortune 500 companies whose products are based on FreeBSD, right?

The same cannot be said for netbsd or dragonfly. To call FreeBSD a "hobbyist OS" shows a distinct ignorance of the market.

Are you contending that those products often run unvetted code? There's a world of difference between the likelihood of these problems being exploited on a servers that aren't shared, routers, small internet devices, and IoT devices compared to shared hosting environments, end user systems (whether they be mobile or desktop) and cloud/virtual server services. Of the latter, I'm o ly aware of FreeBSD being used in any frequency for shared hosting, and even that is relatively rare. FreeBSD just doesn't have the same exploit exposure as the others. But Google compute cloud, AWS, windows, MacOS, and Linux (including Android) definitely are ripe for exploitation.

What do you mean "run unvetted code" - when you've got network facing service, there WILL be remote exploits available. This bug can then be used for privilege escalation. Your understanding of the FreeBSD user base and it being "relatively rare" is so far off base I'm not sure what to tell you. For starters I'd be willing to bet the number of Juniper switches and routers in the wild number in the tens of thousands and they all run FreeBSD. EMC has several storage products. There are multiple firewall vendors. NetApp has several storage products. Etc. etc. etc. Almost all of which are exposed to multiple users, and while some may be behind a firewall, that's little comfort for targeted attacks...

This isn't about FreeBSD not getting a fix, it's about not getting advance notice. If to be exploited you require a remote unprivileged exploit first, I think you are at least an order of magnitude, if not multiple, less likely to be exploited than a cloud vps provider or desktop user that is downloading and running programs from non upstream sources.

I mean, should OpenBSD have received advance notice? What about QNX? What about all those embedded POS system providers? FreeBSD accounts for a very small percentage of high risk systems, and I think that explains this.