Schneier on Security

ab praeceptis • May 5, 2017 5:07 PM

Ben A

Thanks for providing a lengthy and interrupting the flow rehash of HN. I'm quite enthusiastic also about the mix: just about everything ranging from meaningless (to the world) internal bowel movements of the us of a ("district attorney found picking her nose!") to meaningless ("double Block Korkine Zolotarev against LWE"). I particularly enjoyed the source of a wikipedia bit on ZK.

If I may I'd like to add a wee bit of criticism: there is no apple pie how-to.

ab praeceptis • May 5, 2017 6:27 PM

Grauhut (May 5, 2017 5:49 PM)

The evil Russians (TM)! That was the evil Russians (TM)!!1!

Who else (besides all of the nato countries spook agencies) would do such an evil thing?
And how handy! macron hasn't hardy finished vomitting his accusations about evil Russians (TM) hacking him, et voilà, it happens.

I'm wondering, though, how the evil Russians (TM) do evil hacking. After all, as everybody in the west knows, them Russians are always drunk and if they have computers at all then they are rusty and from the seventies!

I bet it was their navy seals! -> https://www.youtube.com/watch?v=0-unYZ6ltfI

ab praeceptis • May 5, 2017 6:47 PM

Thoth

I'm somewhat bewildered to see that you dignify a firefox plugin/add on clusterf*ck with a response at all.

Isn't that exactly what all those add ons and plugins are created for -> clusterf*ck?

Note: This post was written using the firefox plugin protector plugin. Will soon be part of systemd.

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: "F*ck 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 6, 2017 5:43 PM

007BSD

Yawn. 4 critical Xen bugs in 8 years affecting Qubes

a) No. 4 critical bugs that are publicly *known*.
b) Being based on xen was a bad decision. Probably not the only one.
c) The relevant criterion isn't 4 bugs or 40 or 400. It's zero bugs. Anything else isn't secure but in the best of cases less insecure.

Xen can be switched out for any other hypervisor as per the design specs in the future if/when a better option is available.

*Iff* that happened tomorrow morning first thing that would still be after 4 critical bugs.
You may like it or not but last time I looked qubes still is fixed on xen.

Reminds me of "Sorry, Ma'am, your husband is dead, yes, but rest assured that according to our good intentions that was not supposed to happen".

Oh, and btw, look up the term "specification". Hint: It's not about some PR bubbles.

propagandizing

So, presenting evidence that qubes is *not* secure is "propagandizing"? No surprise then that qubes is insecure ...

ab praeceptis • May 7, 2017 7:57 AM

Thoth

You can preach that all day long - in vain. Don't get me wrong, you are perfectly right and maybe one shouldn't just preach but beat it into the people ...

The problem is largely a "cultural" and social one. People have been educated to expect that a) they can buy (or get for foss "free", often signing away their soul), and b) there is some kind of assortment available from bad to mediocre to good (and safe).

What they are *not* willing to do is to be responsible *themselves*. Ergo the always coming up question "What alternative should I buy/use?". After enough failures I experienced when patiently explaining I nowadays just answer "your brain!" Which, of course, will rarely happen.

In a way the people, who basically have been educated to be mere consumers in one way or another are like cornered animals when we tell them that all widely processors, OS, etc, are cluster-f*cked-up.

To get out of that corner they'd need a brain incl. some useful contents - which, however goes against both corporate and state interest (as does being able to communicate securely).

I thought - and obviously erred - that my position was somewhat more comfortable than yours because after all I'm talking to "professionals" (haha). Nope, I'm not; I'm merely talking to the same people like you except that my target audience likes to call itself "professionals" (based on whatever ...).

I'm a human, too, and so I find myself more and more often sarcastic and recommending them to to use the *newest* cpu plus anti-virus. Both of that is obviously utterly nonsensical but not much more nonsensical than recommending linux on arm (8 core, of course, bang bang!)

But there is some hope. This time the europeans and asians didn't sleep over everything, this time they picked up Risc-V quite early and maybe, just maybe this time we won't arm-intel-cluster-f*ck the whole thing up with trustzones, remote management and similar cancers.

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 9:04 AM

Clive Robinson

Or maybe it's one of them "public money pays research but when the project is finished, we cash in via a spin off" ...

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 7, 2017 6:23 PM

Thoth

I'm looking forward in excitement!

And I have an idea I'm immensely proud of (but do not intend to ask for it to be included on the holyday card. You have already enough to do.

But I will introduce it anyway because it's strikingly obvious that my idea will bring "true 100% bulletproof cyber security" to a whole new level. Not meaning to lack modesty but I'm convinced that my idea will contribute no less than RSA did at their time to our holy quest.

Here it is:

Who tells me that a golden "bulletproof cybersecure!" sticker isn't fake? If it is, the wonderful product I'm using might be just 94% secure (like, say, linux)!

What we need and what I hereby officially introduce is a) certificate based signed stickers and b) a golden lock symbol on stickers that are secured in that way.

Just imagine! One could purchase a license for, say, "crap-office", javascript based and running in the browser and have that cozy secure feeling to know that not only is one protected by a golden sticker but that that sticker is trustworthy, too!

All one needed to do was to download the "crap gold-guard" browser add on plus the "crap gold guard" android or iphone app with which one could get an image of the golden sticker which then is transferred to "gold sticker guardians" web service which ocr's the signed sticker id which then can be sent to symersky to be verified who then, if authentic sends back a des encrypted "OK" which then makes the golden lock symbol on the sticker blink 3 times to signal that that golden sticker is authentic and not some evil trick sticker from evil Russians (TM) or evil Chinese (TM).

Just imagine the confidence boost one would enjoy when using crap-office in ones browser being strongly assured that the golden sticker is authentic!

For the moment, though, kindly keep my idea private. I wouldn't want to see "qubeGold" before I've signed the contracts with Symerski.

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 2:59 PM

@Winter

I want to thank you for amusing me and also for ample evidence why the "american century" is ending prematurely and irrevocably.
Please, feel welcome to entertain me with more of your wisdom!

@Ratio

To show good will and fairness and as I just once more happened to suffer from it:

One disadvantage of the Wirth and derivative languages is that some important binary ops are no operators but functions (provided by the rtl or the compiler).

Rather than saying "a := b << c;" one is forced to say something like "a := Shift_Left(b, c);"

While that is of little concern for most application development, it's a major pita in the crypto field; it not only feels unnatural but it actually forces the developer to think in a "bent" way and worse it goes against the law of readability.

Not bad enough to stay away from those languages but certainly more than a small nuisance.

ab praeceptis • May 9, 2017 3:27 PM

Silent Bob

Don't worry. Soon there will be a "protect OS and CPU against themselves browser plugin".

Probably joanna is already working on (and then soon leaving) it.

[You know that you cluster-f*cked up when praying to the flying spaghetti monster seems to be a comparatively promising and reasonable approach vs. secure OSs and products...]

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:26 PM

Thoth

THANKS YOU! I'm overwhelmed and filled with joy.

You have created a true masterpiece, a mons olympus of true 100% bulletproof giga-safe security!
Attaching that powerful sticker to anything, even windows on on xen on x86-amt will immediately turn it into a truly golden symerski-secure system.

Happy Vesak 2017 to you, too

and: cyber! cyber! cyber!

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:21 PM

Thoth

I have deliberately added one of my logo, certified by Thoth, within the Vesak Hoilydays image by the way :)

I confess, I was too much in golden 100% bulletproof security nirvana to notice that.

But obviously that "certified by Thoth" adds yet another layer of golden security. Symerski can pack and leave because I now have the *real gold sticker*.

Maybe one day we'll find the time to add a signature to that. rotl13 plus rsa16 might be an attractive combination; about as secure as Symerski certificates but faster. Do you know how to professionally create buffer overflows in java? After all, we want a real world certificate with the full Symerski and openssl feature set. If java doesn't lend itself well to that we can still use of the many severe bugs on offer in openssl and slighty change it to avoid copyright infringement.

I printed your holiday card and have it near myself to always guide me on my path to security. Thank you very much again!

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 10, 2017 6:58 PM

Spooky

Have you done this before in an actual project (that you can talk about)?

Yes I did, and no, there are quite tight limits talking about it. But hey, no problem, as long as what I say can be found on the internet.

Based on what you tell about yourself I *strongly* advise you to stay away from HOL and coq proving. Your interest is software so I suggest strongly to spec with tla+ or B and to use C plus ACSL/Frama. You'll be rewarded with *very major* differences in productivity. Although, frankly, I cheated a little on that one because particularly for low level stuff you certainly want to use separation logic which adds considerable complexity. But you might get away if you stay away from the kernel itself.

As for DMA things are much worse. The "system" (the proc) itself isn't the major issue. Many say "there's an mmu for that" and are wrong, especially in modern systems with a plethora of processors.

Which leads us (once more, Pardon me for insisting) to the big practical equation:

You see, Nick P and Clive Robinson are perfectly right, but: Well, we don't have the possibilities to build the perfectly secure system; even large corps fail (or find it way too expensive).

But need we? I say "almost always No". Our problem isn't that we don't have 100% security. Our problem is that we have not even 20%, maybe not even 10% with what 99,99% of people use (linux, windows, ... on Cortex A, intel-amt, ...).

Let me remind you of an almost vulgar and profane fact: crypto is almost never hacked (outside labs). It needn't. The OS, libs, and apps offer plenty ways to simply walk by the crypto and not touch it!

THAT is our real problem, *that* is how nsa and accomplices enter our systems. Hence, *that* is what we must work on.

Ergo the probably most important security advice I have to offer is "Cut the crap!". Cut out all those monster crap apps. Don't install apache + mysql + php for the neighbour bakeries website. Don't. Install a small verified webserver and use a small strongly typed scripting language (if you need that flexibility).

Throwing out all that crap and boatware and "made for nobrainer by nobrainers" crap enhances security of the average server BY FAR more than mucking around with seL4 and whatnot.

Second holy rule of ab praeceptis: The higher up you go on the safe/secure scale the slimmer the system must be.

On the normal server level what I said above will bring you quite far. On one or two level higher up you cut even more crap and it's there where mu-kernels are a useful - and adequate - building block. But on that level you don't think in terms of OS but rather in terms of service, as in e.g. encrypting gateway.
Yet another level up *everything* is fully specified and formally modelled, written in Ada, parasail or the like, and fully verified.

Hence, my advice is to think economically and to drive security from, say 10% to 80% with quite little effort rather than fumbling with experimental seL4 mu-kernel (and you *will* end up with an experimental version if you want to go that way!).

Maybe this also explains why I like OpenBSD quite well. You get all the goodies and candy of a posix OS, reasonable quality (as opposed to, say the linux toy box) and even - and that's VERY important - quite some stuff above the OS, things like all the OpenXXX stuff from the OpenBSD people.

Final remark to show the weirdness of the whole field: Everybody and his dog want hypervisors to do *more*. Well, I sometimes intentionally chose one that does very *little*.

security has something in common with elegance. It's not about adding what can possibly be added but it's about cutting out what can be possibly left away.

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 11, 2017 5:24 PM

Clive Robinson

Well, there's a reason for (not just) my holy rule to keep it tight and slim.

And, yes, I posit that any not small (and I mean tiny) code/project body not using formal methods is bound to become a trouble generator. And that's exponentially so the bigger a project gets.

But I do also understand that one needs existing developers and existing, established languages with good tools available. That's one of the reasons why I'm lenient re. OpenBSD.

But the problem with linux goes way deeper, it goes down to the mindset and sectarian level. Just remember linus, the young student arrogating a position from which he attacked Tanenbaum, a well respected and experienced professor (and developer with lots of code under his belt). Or think ab esr and his utterly absurd anti-cathedral paradigm that, certainly not by coincidence, was to be found at the heart of linux, too. Or think about all the political activism incl. i.a. fights for something like a women quota and other idiocies that would be expected in a mental asylum but not in a major project with billions of $ in its back.

linux is the opposite of engineering. It started in the mistaken and arrogant believe of a youngster that ignorance, chuzpah, and social activism could somehow achieve a better OS than experience, a properly trained intellect and proper engineering.
It's cynically funny that "evil microsofts" chances to sometimes come up with a reasonably safe OS are BY FAR greater than linux' chances. But then microsoft has engineers and they have understood what's the wrong way and what's the right way, and they threw very, very much money at the problem and at building better tools.

In the end it's simple: We need to use adequate languages and, at least for the core (kernel, drivers, core libs), we need to use formal methods. Anything else is irresponsible. Moreover we must avoid mega monsters and rather design with modularity in mind,

Btw, I'm right now working on some academic crypto code by a (otherwise very intelligent and capable) professor whose code - like so often in academia - is obviously written as a hated but necessary task. The math is brillant but I'm working on repairing the 3rd major error by now! It's about bit fiddling with an unsigned 64-bit integer which should result in a 32-bit integer to be fed to the next stage. Well, the value actually passed is a *36*-bit integer ...
Chances are they never noticed it because C (it's written in C) happily eats sh*t and produces sh*t without any complaints.
My Ada implementation immediately threw an exception and told me the exact reason. Gladly the error is just based on carelessness; the algorithm itself is correct (theoretically) so I could repair it.

Three lessons to learn (minimum): a) a professional compiler for a professional language is a powerful assistant, b) C should be used only by experienced, responsible developers and only where necessary, and c) if there are problems then *I*, the developer, should be confronted with them, *not* the end user. In other words: Catch problems and errors *early*! The earlier the better (which is yet another reason for proper modelling, which they didn't do).

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 12, 2017 3:38 PM

Thoth

Fully purpose built from scratch by hands would be much better than having a full blown *NIX or Windows OS running on top with all their nonsense.

Right. That's the point.

And it's the reason that ticks me off when I see idiots playing with "real time linux". That's insanity to the cube.

For some safe and secure device with a specific task one (well, a grown up engineer) wants *as little OS and libs* as any possible.

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 12:51 PM

Who?

Well, so so. Sure, it's nice from Lenovo to patch older products, too, but a) that doesn't make amt somehow better and b) that also backports the newer perversions those older systems didn't yet suffer from.

We must look deeper to understand.

Probably some now will lament again how much of an us-american hater I am. No, I am not. I do *not* hate "the us-americans", i.e. the people, the vast majority there. What I do utterly reject is their system, the 1%, and their unholy corporatocracy - deep state alliance.

And the whole thing is not merely a question of personal likes and dislikes. They did i.a., which is relevant for us, completely (and brutally) control vast portions of IT and particularly the processor technology. Other countries were completely dependant - and kept dependant - on the us of a masters.

There are but 3 exceptions: The Russians (earlier), the Chinese (only later), and the french (which is a story in itself. The french understood the threat and had both the capable intelligence services and the capable academia to always be somewhat behind but not utterly dependent. Think, for example, Inria and ST).
Everybody else had but 1 way, namely to beg - and dearly pay - the us of a for IT basics, in particular processors.

Another "coincidence": Oh, please, feel absolutely free to buy alternative products! Unfortunately, it just so happens that there are none. You want an alternative mainboard with an alternative processor? Good luck. You'll end up either with plain x86 or arm or with something using a processor from a fabless company, typically built on some us or uk patent and manufactured in a us-controlled fab (and with little and exotic OS and driver support). But there is powerpc and sparc, you say? Look at the companies behind that and think hard ...

The "marriage" behind that thriller is a unholy as it is lucrative in more than one sense. The corporation make billions upon billions in profits (btw: Does anyone seriously think they won't dance 100% to the deep state tunes and risk losing those wonderful billions and private jets?).
But the real Bang is what the deep state gains: A panopticon world, "citizens" (read working, consuming, tax paying herds) that are completely transparent and easy to manipulate. Every dictators wet dream!

But there are still universal laws and they still hold. One painful (for them as well as for us, if for different reasons) example: Unbounded greed always spawns children with lots of defects. The very "let's cut corners" and "sloppy is good enough" greed attitude that promises even more profits (3 cents here and 2 cents there) also creates holes in the wall. To some degree that was even desired as those holes were attractive and useful for the spooks but there is another factor they either didn't see or didn't care about: The us of a system is mercilessly dumbing down people - and that's also true for their own goons.

Also important: You don't win that war staying with its mindset (the producer/consumer/market mindset). The solution is *not* to buy something alternative. First, there is no real alternative (well, there is, but neither the Russians nor the Chinese will sell it. It's far too strategically, tactically, and operationally important). Second, you'd simply end up with the same problem (maybe slightly less obvious) in another colour. Because, you see, you'll want to run software on your alternative hardware. Tell me: How is running crapian OS on architecture B more "secure" than running it on arch. A? And the libraries or, say, ssl/tls, is that somehow magically more secure on architecture B?

You win that war by using the weakness of the enemy against him and the strengths you (hopefully) have for yourself. As this war happens to be one fought in purses and minds, the human intellect can be a sharp sword and a mighty weapon that at the same time weakens the enemy and strengthens us.

It's about properly thinking, properly designing, properly implementing. *That* is our strongest and most promising approach and weapon.

For more than one reason, btw. Example: A well educated and intelligent human will by nature tend to be against oppressive systems. Which translates to at least a considerable part of the us of a intelligentsia (all 5 of them, haha) being on our side.

But back to the core matter. Any war with untrustworthy communications is a lost one. We *MUST* be able to communicate confidentially.
To achieve that goal under very poor circumstances (with pretty much everything set against us) we must first fully and correctly understand the problem. "have everything airgapped" isn't good enough. That may be good advice to Jane and Joe but to win (or even fight in first place) the war we absolutely need a clear and full understanding of the problem as well as of the situation.

The mindless "obscurity is not security" sectarian blabbering is an example. Let me offer you a concrete and simple example, a prng: such a thingy has 2 stages, namely a state change stage and an output stage which (hopefully) decouples the output from the state. In other words, there is an obscurity stage!

Why am I hunting that matter down so vehemently? Because a war is lost if the enemy succeeds in defining your thinking space and way of thinking. The truth is, in fact, that obscurity has been and still is a very major element in warfare. Sometimes as simple as hiding your tanks under "naturally looking" fabrics or even tree branches and brushes, sometimes as complicated as frequency hopping with multiple factors (not just the frequency) being prng controlled.

And yes, all of that also means that to not be condemned to loose the war we must understand that we are in a war and not in some comparatively cozy small village problem like Joe and Jane being eavesdropped on by the evil village cop.

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 3:35 AM

Ratio

You consistently abused (not only my) friendliness and patience. I'm not interested in your games.

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 + 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 16, 2017 11:28 PM

Grrrr blog formatting ...

The "with Pre" line above should be

with Pre => (buf'First <= idx) and (buf'Last >= idx + len * 2);

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.

ab praeceptis • May 18, 2017 3:53 AM

Clive Robinson

I'm enchanted to see that there are green stickers, too. And they seem to work just like the golden ones. Great!

ab praeceptis • May 19, 2017 2:54 PM

Ratio

answer to multiple times disqualified person not deserved.

Have a nice day.