Schneier on Security

ab praeceptis • May 6, 2017 12:14 PM

@all

• qubes – Funny news:

Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).

Money quote: “XSA-213 is a fatal, reliably exploitable bug in Xen.”

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt

In other words: There is no such thing as a “secure OS” on an insecure hypervisor.

Have a nice weekend.

ab praeceptis • May 6, 2017 4:00 PM

Clive Robinson

Two quick remarks.

I see a considerable danger in qubes and similar as they risk to lull users into an utterly wrong perception of being secure.

And: Yes, it’s a long and ugly way (largely thanks to stupid, careless, greedy profit driven people, usually in the us of a). And yes, creating, say a really safe OS seems useless as the whole stack, hardware and software, must be safe to get a safe system.

On the other hand that’s a classical problem; Each of A, B, C, D, and E pointing at the others and saying “it’s not sensible anyway to do my part well as without all the others doing too we won’t arrive”.

My (and certainly not just my) response: “Fck you! *All of us will work and each bit of work that is done is some progress that also positively influences the other parts!”

And btw, man does it feel good, to have even just a small block, say prng of good quality, modelled, examined over the full domains and ranges, and implemented in spark’ed Ada!

ab praeceptis • May 7, 2017 8:08 AM

@Who? @es MaUg

That whole Snowden vs ab praeceptis thing was braindead in the first place and on multiple levels.

We know little, very little about Snowdons capability to create more secure systems. At the same time ab praeceptis isn’t working for the spooks and almost certainly knows quite little about the spook universe. Short, he and me are living and acting in completely different universes.

I didn’t read es MaUgs post but I guess it went along the line “ab praeceptis is a nobody and snowden is the demi-god who singlehandedly f*cked nsa and is still alive and in freedom, hence whatever Snowden used or said is like gods word and everybody caring about security must use qubes!11!!!”.

But there is that ugly little thing called reality in which qubeos was found at least 4 times to cluster-f*ckup. And that is not even surprising as “snowdens favourite golden-sticker-secure OS” bet on xen.

Does that tell us that Snowden is an idiot? Certainly not. But neither does “Snowden uses qubeos” tell us that qubeos is secure.

We need a golden “secure!” sticker for qubeos. Plus a Symersky security center app.

ab praeceptis • May 7, 2017 10:52 AM

es maug

Sorry but it seems that you completely failed to understand the field and events you’re talking about.

Snowden was successful because nsa is insecure in many ways, too. In other words, nsa could be hacked and plundered pretty much for the same reason the local bakeries systems are hacked and plundered.

Obviously the creation of safe and secure software and not being successfully attacked are related to a degree, but Snowdens success wasn’t due to him using qubeos, tails, or whatever – it was due to nsa being utterly vulnerable, i.a. due to lousy OpSec.
Add to that the bigmouth bragging factor and the “security by bureaucracy” factor so commonly seen with (not only) us of a agencies.

And then there is another, somewhat related, but basically entirely different question, namely how Snowden escaped and how he stayed in contact and exchanged information with diverse people. Snowden doesn’t look exactly shiny in that regard. Keep in mind that almost certainly he could be tracked to HongKong and to the airplane out of HongKong because he had excessively lousy OpSec himself; striking example: Inviting journalists and having his face over TVs around the globe while not yet at his final destination and (hopefully) in security.

Now, does that say that Snowden is stupid? Not necessarily; he might have acted that way because going public seemed more important to him than staying secure.

Oh and kindly refrain from calling me “ego-involved” when I react on a post explicitely mentioning (or addressing) me.

ab praeceptis • May 9, 2017 12:45 PM

Winter

a) Russia needs no dirty tricks. They have a very capable military to deal with any nato countries having funny ideas. Moreover, they have a capable president who would actually get more votes in quite some nato countries than their own regime people.

b) Which part of “repeating allegations over and over again does not constitute proof” did you fail to understand?

Have a nice day, Mr. mc cain’t jun.

ab praeceptis • May 9, 2017 5:52 PM

Nick P

Absolutely – if only there wasn’t the ugly downside of millions upons millions of people being totally f*cked.

ab praeceptis • May 9, 2017 7:15 PM

btw,

“You are stuck with me for another 6.5 years” turned out to be yet another wrong guess.

Bye bye Mr. cyber-com(ic|ey) …

ab praeceptis • May 9, 2017 11:29 PM

@Moderator

I just saw that you merged my correction into my post. How kind of you – thank you very much, helpful friendly “ghost” 😉

ab praeceptis • May 10, 2017 12:50 AM

Spooky

Sorry, no, not beyond playing around with genode and looking at the sel4 source. It doesn’t make much sense for me to gain more experience because neither sel4 nor qubeos are with the frame of my interest/needs.

And btw, it should be kept in mind that putting something insecure (OS or applications) on top of a mu-kernel and/or hypervisor doesn’t make the whole thing somehow secure (but it can mitigate to a degree). Which boils down to “qubeos is not secure but less insecure” – I strongly advise people to keep in mind that “less insecure” <> “secure”!

If you want safety (or at least something much closer than e.g. qubeos) you should get a good quality product of the kind of software you need, say a http[s] server and put that directly on top of the mu-kernel.

Doing that you would also burn into your mindset one of the few actually relevant and helpful rules, namely “keep it simple and small!”. The fewer loc the higher your chance to get something actually safe.

To stick to the web server example (which probably is not uncommon to be desired) what you want to do is to find one of reasonably good quality (which usually translates to “not utterly crappy”) and to then a) strip the source down to the minimum functionality actually needed, b) run the rest through some actually useful analyzers (e.g. predator) and c) to “armour” the code to be able to statically verify it.

From what I see all the common and luxurious “put OS [whichever, say qubeos] on top of hypervisor and/or XYZ” don’t bring you really safety and (funnily, that’s quite consistently ignored) to make that work will quite probably be more and complicated work than to create safe versions of the few critical services needed (like e.g. http).

And attempts to make any full inbl. kitchen sink OS somehow magically secure by putting a hypervisor and/or mu-kernel beneath seems quite futile to me.

Kindly note that my advice is also in a way yet another version of the classical “When you talk about ‘secure’ be sure to be able to properly specify your situation, need, and threat scenario!”.

Making linux secure is a futile undertaking. They’ll never even catch up with OpenBSD (which again is not secure but considerably less insecure than most).

Creating a system that provides well specified and not too many and complex services in a reasonably secure way, however, is feasible for a small group with some experienced leads knowing the field and the tools and ways. In that case sel4 might be one of a few sensible choices to build on.

ab praeceptis • May 10, 2017 12:33 PM

PEN4

I feel that you are too hard on OpenBSD. Had you said the same about Minix3 I would accept it. But OpenBSD is a quite complete OS – which is actually bad. Let me explain:

Obviously the OpenBSD people can’t tell you much, let alone give anything even remotely looking like a guarantee, about the plethora of third party applications. But it’s that which makes an OS seen from the user perspective, particularly with the kind of “I just need to get stuff done” users.

What OpenBSD can do – and does try hard to do – is basically two things: a) a good posix kernel and b) at least some mitigation or prevention attempts for misbehaving or insecure third party software, say libreoffice.

That said I feel you are unfair because OpenBSD offers pretty much the same set of application stuff that linux offers. Somewhat less but all the basics are there.

If I’m to chose between running libre-crap-office on linux or on OpenBSD I’ll chose OpenBSD every day of the week and twice on sundays.

ab praeceptis • May 10, 2017 1:39 PM

Spooky

I’m not sure you’ll like what you see. Not that seL is bad or something, there are just lots of buts. Running on “modern x86” (which usually translates to intel atm) and Cortex A (read Thots remarks about trustzone …). Much of what you would probably strongly desire only available in experimental stage, etc.

Plus uncomfortable (but understandable) assumption like “No DMA”, i.e. all verification is based on a set of assumptions which are reasonable from their POV but certainly not what most actual users want.

Well noted, my statements are not in any way anti-seL4! You will make quite similar experiences with other mu-kernels and proven correct stuff, too. What I want to say is that there should not be an expectation to compile and install sel4 as a base block and to then simply add software.

(Based on my own experience with another mu-kernel) the reality is more like “find, get, and build some basic dev tool chain, port vital drivers, and do lots of (not at all funny) cross dev (typically with C and ASM only). Plus, of course “learn about all the ins and outs nooks and crannies of the mu-kernel”.

Unless you have lots of experience and lots of time I strongly suggest to start building at a higher level, maybe something like genode.

Finally, keep in mind what Liedkes work (and hence the whole L kernels) ware about and that those kernels were basically research projects. That does not mean they’re unusable in real world but it certainly means that a lot of work is to be done. Liedkes quest was “can mu-kernels be made less painfully slow? If so, let’s do that”.

Finally, keep in mind that their whole proof system is not software but math centered and about the most painful way to verify software correctness unless you happen to have a math department and plenty phd and master candidates down the floor …
However, you must keep the “proof chain” alive through everything which translates to your part of the work getting painful and inefficient.

Those are some of the “little details” one needs to know for such adventures. One such detail I learned is to be sure that I can live and work well with the spec and verif toolchain of a given project.

My advice: Wait a little bit. I quite sure that soon there will be a tla+ verified [mu-]kernel around. That’s a much better and more efficient basis.

ab praeceptis • May 11, 2017 12:35 PM

Clive Robinson

Thanks for the link. Not that there weren’t enough other reasons to show that linux is not the solution but the problem, but that is a particularly nice one.

That AF_PACKET bug really demonstrates on multiple levels what an utterly incompetent toy lab is behind the sectarian linux “geek” kindergarden with plenty rich and careless corp parents involved, too.

The most nightmarish thing about the whole linux thing is that they still do not even begin to realize what a gigantic cancerous waste dump they’ve created.

ab praeceptis • May 12, 2017 3:32 PM

Anonymous Coward

Isn’t that like saying that Microsoft should be avoided, just because MS-DOS was originally written by one person with no professional experience?

For a start, bill gates wasn’t alone. Moreover he didn’t build Ms-Dos but had a pre existing base. But that isn’t the point. The point is one of attitude and competence.
Well noted (and I ocassionally mentioned that here) I wasn’t any better than linus when I was 20 or so. Probably with 20 or so pretty everyone is more or less condemned to be an idiot in a way. I certainly was one. Unlike linus, however, I did listen to my professors (well the competent ones …) and I would profoundly think about it before going against established wisdom.

“Attack” – yes, linus attacked Tanenbaum. He basically told him that he was yester-decade and wrong and that he, linus, knew much better.

But my point isn’t linus. My point is what all of that (incl. his arrogance and cluelessness) led to.

Are you saying that political correctness is limited to Linux? Aren’t such “affirmative action”/”equal opportunities”

I don’t care. That’s political and sociological bullshit. Good technical products need good engineering, period. That said, I don’t care what’s between the legs of a capable colleage nor about his sexual, religious, or political preferences. I became quite good friends with a quite high up woman at IBM; I didn’t and don’t care and I never excluded women, yellow or whatever people or lesbians or … – I did, however, always look for competence and brains.

If some weird regulations demand quotas, oh well, then one creates a looney bin for the legal requirements and a workshop for the actual work. Unfortunately many projects mix that up.

Why not then diss everything Microsoft since Microsoft employees have called the GPL an evil “virus” that needs eradicated?

Front up and well noted: I was known to be a fervent microsoft hater for decades. That said, they were damn right with was just quoted and I wholeheartedly agree.

The gpl is a major evil and a major culprit ruining the software landscape and businesses. It basically says “the stuff is free but you will be subdued slaves of our ideology”.

Well noted, I’m not against libre or oss. In fact I have given away code decades ago under what would today be called a bsd license or similar. I’m against gpl specifically.

So when academics work on Linux, it makes Linux bad because “That’s why it is the hardest part to get right and most school trained programmers avoid it in their quest for shiny new algorithmns that display their sense of being a brainiac.”

Bullshit. You mix up two things. a) Very many, probably most, linux developers are incompetent amateurs (even if they happen to be good C “hackers”). Mastering some PL doesn’t make one a good software engineer. b) Many, if not most, software written by academics in their field and linked to some research project and/or paper is lousy or at best mediocre. That’s no attack from me but an observation. I can even feel with them. Writing an implementation of their stuff is probably emotionally similar to us being forced to to bookkeeping; must be done but we don’t like it.

at the same time Windows is superior to Linux simply by virtue of being for-profit and only hiring engineers with golden stickers(college degrees)?

Not at all. But – and that’s an important but many tend to ignore: When hiring engineers for money one can demand some things like for example that they work professionally. In an oss project one (usually) can’t. Moreover the value systems are entirely different.

Isn’t it harder to repair errors in Windows, since you have to do it without the source code (RTFB)?

A rather theoretical question as usually it’s people with access to source who do that. Also, please, do not equate microsoft = windows. When I speak of microsoft nowadays I’m talking about the company who (finally!) has see the light and is investing big money into research in all fields that are relevant to safety, reliability, security. And about a company that seems to have understood that an OS (or other major and sensitive project) should probably not be written in C/C++/java and the like.

ab praeceptis • May 13, 2017 6:34 PM

@All

Ad “intel amt”

Suppose intel amt were not bad enough and some insane jerk wanted to turn it into an even higher risk lottery. How? What to do?

I’m glad to inform you that intel has found a solid way to make the amt cancer by far worse. In case you couldn’t already guess it: Yes, there is java, too.

The looney bin of idiot corp at your service!

ab praeceptis • May 14, 2017 2:28 PM

Who?

“obscurity as security” model but I do not trust a lot on it either.

Then throw away all crypto because crypto is obscurity done professionally (well, more or less …).

You see how deep seated the brainwashing is? Logic tells us one thing but psychological mechanisms (like ever repeated “obscurity isn’t security” incantations related ones) keep as mistrusting, just as was desired.

“guerrilla warfare.” It certainly works, and when correctly implemented works well, but sadly it does not scale. One cannot preserve “obscurity” when his communication requirements grow. It works for small teams.

Partly yes, but not at the important core. That’s the beauty of verifiable and proven algorithms and implementations. They work on any scale.

But I agree insofar as I myself occasionally find something (e.g. here in this blog) that seems to be a major problem but I happen to see a solution and keep it for myself as telling it would also hint the enemy, Which leads us back to what I exclaimed to be the conditio sine qua non -> We absolutely need confidential (and trustworthy) communications!

Moreover we must not forget that even the very core, crypto algorithms, are not to be simply trusted. One current reminder is the logjam attack, the paper on which just resurfaced these days. One of the take aways? “tls is broken”. “Funnily” (or not so at all) that paper did not even mention the plague of “probable primes”, upon which major parts of crypto are based. “Probable primes”, to make that clear, are an open invitation to nsa and accomplices to f*ck us; one reason being that that kind of problem class boils down to “who has the big resources will be using it and who has small resources will be the victim” (as is also visible with logjam, btw).

Frankly, crypto has become a) omnipresent, b) vital, and c) not or even misunderstood by 99+% of the people and users. And that not-understanding is virtually all encompassing. Example: I rarely see a proper threat analysis; quite usually the approach is “protect! somehow. and against something. whatever. protect!” – which, of course, is bound to fail.

Just look at the ssl/tls nightmare. nsa are laughing their a**es off while Joe and Jane dutifully (and cluelessly) update their software and firmware – and nobody uses common sense it seems. Example: Just look at the tls 1.3 presentation. 10 minutes of excited stuttering by that boy on stage and everyone with some healthy common sense should know, even without any crypto knowledge at all, that tls 1.3 is continuing the clusterf*ck tradition (those with crypto knowledge should have a carpet ready to bite into).

ab praeceptis • May 14, 2017 9:46 PM

Thoth

I’m enchanted to see that you are already thinking about the next “golden 100% cyber bullet proof sticker” round! And it’s needed. The only thing that can protect us is golden stickers, preferably let’s encrap signed ones!

But aren’t you too stringent proposing JSON Web Tokens? Shouldn’t we just generously include the whole “web 2.0” creepy looney bin?

ab praeceptis • May 15, 2017 6:02 PM

THE Lizard King

No, I did. It’s, however, speculation as we don’t known intels strncmp implementation.

Chances are, I think, that it’s an unhappy mixture of different factors, one of which probably (but not certainly) is the function implementation; another one is the misguided design of at least many strncmp implementations which (mis)take length 0 to always match.

Another reason why I didn’t take a closer look (and also didn’t write about any details) is the fact that I take someone doing that kind of job in C and then adding java to the mix to be such an utterly stupid and incompetent f*ck that a closer look at his “work” is neither needed nor merited.

ab praeceptis • May 16, 2017 11:25 PM

Ratio

For a start: I don’t care a rats a** about the C standard. In my world, PL standards follow logic and not vice versa.

And matchingly (g) you make the error of assuming that what I said was possibly related to a C standard. It is *not – other than saying that they got it wrong (as was to be expected). Plus, of course, they invited people to mistake the whole matter.

A string, i.e. an array of chars, is matching another string, when both arrays have the same length plus the same content. That can be expressed as a proposition:

let A and B be strings (arrays of chars)
let La be the length of A; let Lb be the length of B

La != Lb => A != B

(Iff La = Lb then) A[n] == B[n] for each n \elem 0..La

If that holds A and B match. End of story.

But C being C they, of course, had to create arbitrary definitions and add some confusion to that. Like the xxxncmp bunch. What is that ‘n’ to mean? The desired comparison length (let’s not ask for reason …)? Or is it to protect against senseless or even dangerous “compare over the length of the longer string” operations? “But”, you say, the funny “standard expressly states that the comparison stops anyway at \0”? So what? Who says those strings are terminated? “But”, you say, that’s wanton!”? Nope, not more arbitrary than “compare n chars of two strings”.

To finally clusterf*ck it up, they add yet another layer by comparing for “less” or “more”, too. Well, that’s a completely different playing field but than, we are talking about C and cramming additional functionality, no matter how nonsensical, is a strength of C after all …

The result? Worthless crap whose major real functionality is to create confusion and bugs, it seems.

Let me provide you with a glimpse into a much better (and more elegant, too) world. Assume caller passes in a buffer and a starting index at which callee is to hex “print” a desired number of bytes of something, say of a 64-bit unsigned int.

In C lingo:
// hex print ‘len’ bytes of ‘value’ into ‘buf’ starting at buf+’idx’ …
buf_hex_print(char *buf, unsigned int idx, uint64_t value, unsigned int len)

Oh no, wait, according to “good C practice” we should add the size of ‘buf’. So, let’s create buf_hex_n_print with an additional size_t telling callee about the size of ‘buf’- I wish you fun implementing that properly.
Well noted, I know pretty much nothing about ‘buf’ and I’m depending on quite some premises like buffer being large enough or properly \0 terminated and caller not telling me lies (maybe unintentionally; happens easily in C).

In Ada lingo:
procedure buf_hex_print (buf : in out String; idx : Integer; value : Unsigned_64; len : Positive)
with Pre => (buf’First <= idx) and (buf’Last >= idx + len * 2);

Et voilá, now I know – and can verify – i.a. that:

• ‘buf’ is not null
• ‘idx’ is not before the start of buf
• ‘buf’ is large enough for the job (hex needs 2 chars per byte)
• ‘len’ is > 0, i.e. I won’ttry to print 0 or even a negative number of bytes.

Note that ‘buf’ may start at 0 (C), or 1 (typ. Ada), or even at -22 and my procedure will still work fine.

ab praeceptis • May 17, 2017 12:19 AM

P.S.:

Any formatting stupidity of myself is not my stupidity but the evil Russians (TM) did it!!1!

Or maybe, for the sake of fairness, it’s the evil North-Koreans (TM) did it!!1!

You don’t believe me? Wait for the washington post or cnn or new york times picking it up! In fact, they make a living with “the evil <insert evil nation du jour> did it!!1!”.

Addendum: I’m sorry to inform you, evil Mr. Trump (soon trademarked), that you are only in third place. Maximum. But with a little patience and a an occasional polite sentence to some russian statesman you might overtake evil North-Korea and reach #2 right behind evil Russia….

ab praeceptis • May 18, 2017 1:35 AM

Ratio

You obviously don’t know what you are talking about re. more and less. Hint: more and less need meaning, equality tests don’t.

Moreover you – not at all surprisingly – largely avoided my C vs Ada example. In my Ada version I have everything I need to avoid whole classes of bugs while in the C version I have but some promises that can be (and often are) lies.

As this place here happens to be about security I do care much more about security relevant aspects than about your mindless C standard citing.

Oh, and btw. the function I used as an example came from current work on implementing some interesting crypto stuff in Ada or, more precisely, from the crypto stuff whose original author has an error in his C reference implementation which he didn’t notice because (I did test that) C happily compiled it where Ada immediately complained and clearly told me about the error.
Which in the given case means that his math is correct, his reference implementation, however, is not. Congratulations to all the happy reference implementation users whose prng has a significant bias due to C being a clusterf*ck. nsa and cia will be pleased.

But don’t you worry, just continue your private preaching and “I know better!” crusade – just not with me. I’m not interested in your mindless blabbering.