Handling of CPU bugs disclosure 'incredibly bad': OpenBSD's de Raadt

>itwire.com/security/81338-handling-of-cpu-bug-disclosure-incredibly-bad-openbsd-s-de-raadt.html

Disclosure of the Meltdown and Spectre vulnerabilities, which affect mainly Intel CPUs, was handled "in an incredibly bad way" by both Intel and Google, the leader of the OpenBSD project Theo de Raadt claims.
"Only Tier-1 companies received advance information, and that is not responsible disclosure – it is selective disclosure," De Raadt told iTWire in response to queries. "Everyone below Tier-1 has just gotten screwed."

Details of the bugs were published on the Web on 3 January though there had been an understanding that disclosure would only take place on 9 January, that being the day when Microsoft is scheduled to release its monthly security updates.

The reason for this is because the bugs mainly affect Intel CPUs and Windows is the operating system that has the biggest share of such processors.

Google justified breaking the embargo, saying: "We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."
The reason why such bugs had come about was put down by De Raadt to Intel's desire to stay far ahead of the competition; hence it had played "fast and loose".

Meltdown removes the barrier between user applications and sensitive parts of the operating system while Spectre, which is also reportedly found in some AMD and ARM processors, can trick vulnerable applications into leaking the contents of their memory.

Other urls found in this thread:

wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
gnu.org/philosophy/javascript-trap.en.html
marc.info/?l=openbsd-misc&m=151527756600887&w=2
pkgsrc.org/
pkgsrc.se/
openbsd.org/policy.html
media.ccc.de/v/34c3-8968-are_all_bsds_created_equally#t=415
twitter.com/SFWRedditGifs

(cont)
"There are papers about the risky side-effects of speculative loads – people knew, and as a result no other vendor's chips does speculative loads (Meltdown – Intel Only) in a significant way," said de Raadt who heads a project that has an enviable reputation in that it has had just one remotely exploitable bug in its default install since it started in 1996.

"Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies – so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk," he said.

"It is a scandal, and I want repaired processors for free. I don't care if they are 30% slower, as long as they work to spec. Intel has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes."

De Raadt found an analogy with the Volkswagen emission issue. "Some VW executives probably wish a problem with their brake controller software has been discovered at the same time," he quipped.

OpenBSD has a good reputation for security and runs some of the public servers with the longest uptimes. De Raadt himself is obsessed with security, and has as his aim the provision of an operating system which has a secure default install.

Given that, his barely suppressed anger at the security snafus revealed last week was understandable. "I am terrified of where this leads. Intel architecture is already very inconsistent, complex, and difficult to deal with," he said.

"Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture. This tricky component of kernel software is now becoming more complicated than it was in the past. We are used to hardware hiding the complexity and providing a uniform safe view."

De Raadt said there would be a "big price to pay for the complexity of handling exposure to the micro-architecture down the road, mark my words".

"Decades old trap/fault software is being replaced by 10-20 operating systems, and there are going to be mistakes made."

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Why not both?

Well Theo would never be told anyways because OpenBSD wont sign NDAs.

I wonder how many "open" source projects signed a NDA like Ubuntu? I think that is the biggest issue here.

wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

They don't sign NDAs but they will out of politeness not announce their fix for a vulnerability for about a month.
The recent OpenBSD KRACK debacle at least shows that if push comes to shove, OpenBSD puts their users first.

Yes.

That's why I would like to know how many other "open" source projects signed a NDA?
If they did they picked protecting INTEL and the CEO's stock options over their users. And they did it all for FREE.

>Only (((Tier-1))) companies received advance information

You seem to think that the two are mutually exclusive

obfuscated uncommented source code is not open source. ie these kernal patches.
gnu.org/philosophy/javascript-trap.en.html

In fact I wonder if release these types of obfuscated kernel patches under the guise of NDAs and "embargos" is in violation of it's own gnu license.

can you take your source code, strip all the comments out and obfuscate it, and then still release it under the GPL v2?

OpenBSD/armv7 seems mostly unaffected by either bug. I know what architecture I'm buying next, and it's not Intel.
marc.info/?l=openbsd-misc&m=151527756600887&w=2

POWER for me

No if they were putting their users first they would change their license under the GPLv3.
But of course I bet that the bsd team just considers users the companies and developers who contributes and not the whole people who use their software.

No. That is not considered source code.

how can the kernel get away with it then? i guess it's because it's the kernel and linus can do what ever the fuck he wants with zero repercussions, while anyone else who did for lesser software would have their packages taken out of the repo's.

hmmm

Wrong. OpenBSD users don't give a shit about GPL or Stallman's ideals. OpenBSD team has delivered a relatively sane, secure, open-source OS for some decades, and that's all we care about. If someone forks OpenBSD and closes their branch, we don't give a shit, because the OpenBSD developers are always going to be much better than any lame asses corporates like Intel, Google, Redhat, and so on. That closed branch will end up rotting away, as it deviates more and more from OpenBSD's current state. That's why the corporates use Linux instead, because they can shove their requirements like systemd into users' asses, with very little pushback.

It is source code, comments are irrelevant.

obfuscation or intentionally difficult to read code + lack of comments = not source code
i'm not arguing lack of comments is the deciding factor.

What's the software availability like for OpenBSD. I know FreeBSD has fresh ports or whatever.

...

That's not how source code is actually defined though. Every piece of software I've written is difficult to read and has no comments, but it still compiles properly so it's source code. If I gave it to you, it would compile into the same binary and work the same way, with no features absent, so it's source code.

Have those even been tested for Spectre? Indeed, relatively less exposure means less eyes on the hardware and potential bugginess, open specs or not.


They've got their own ports tree with lots in it, but don't expect all of it to work well. In particular, bloatware tends to trip over itself when having to deal with a stricter OS.


When I heard that comment it sounded like shitty bait to me. Why is it getting any attention?

Their ports tree is "meh" but for the most part I never had anything go bad using it. If something doesn't work they will take bug reports for it.

But now I just use pkgsrc on everything tbh fam. Open/Net/OSX and even Linux.
pkgsrc.org/
pkgsrc.se/

done

Sadly, that's not the case. They actively avoid GPL software like the plague. NetBSD and DragonflyBSD seem a lot less license autistic than the big two.

How is it compared to a portage prefix?

He probably means strong disagreement rather than apathy.

openbsd.org/policy.html

Their idea of freedom is different from the FSF (c.f. positive vs. negative liberty) and they want at least their base system to uphold that. GPL is specifically hated because of its viral nature.

I do not know. I never tried it so I couldn't give an educated reply. The thing I like about pkgsrc is everything is self contained under /usr/pkg so things don't get tangled up in the host OS. If things get really fucked up you just 'rm -rf /usr/pkg' and your back to square 1 with out having to reinstall the whole OS. It looks like prefix does the exact same thing.

There is nothing viral about the GPL. The GPL is only viral if you consider copyright law to be viral.

When it comes to mixing GPL and BSD-licensed code the former trumps the latter when applied to the whole. Not desirable from their standpoint of allowing anything to use OpenBSD and its code, even proprietary software.

There's actually a lot of GPL (and other various licenses) stuff in the ports tree. But users generally shy away from ports since they're not as safe or well-designed as the OS itself. Plus if you're running -current, it makes upgrades easier when you have less packages installed.

Handling of OpenPlacebo security is 'incredibly bad': Anyone with a Brain
media.ccc.de/v/34c3-8968-are_all_bsds_created_equally#t=415
Thanks, the rat. And since there are no further mitigs such as MAC, you have no way to ever insulate yourself against the rat's security holes, unlike everyone else.

Thanks, Holla Forums. This board wouldn't be the same without you.

No. Whether you still consider it source code or not is irrelevant, because that's not what the GPL asks for. The GPL asks for the preferred form for modification.

bump