Slashdot Mirror

Quote from here: https://blog.regehr.org/archiv...

The new Power had no weapons on the ground, nothing but a comm laser. That could not even melt steel at the frigate's range. No matter, the laser was aimed, tuned civilly on the retreating warship's receiver. No acknowledgment. The humans knew what communication would bring. The laser light flickered here and there across the hull, lighting smoothness and inactive sensors, sliding across the ship's ultradrive spines. Searching, probing. The Power had never bothered to sabotage the external hull, but that was no problem. Even this crude machine had thousands of robot sensors scattered across its surface, reporting status and danger, driving utility programs. Most were shut down now, the ship fleeing nearly blind. They thought by not looking that they could be safe.

One more second and the frigate would attain interstellar safety.

The laser flickered on a failure sensor, a sensor that reported critical changes in one of the ultradrive spines. Its interrupts could not be ignored if the star jump were to succeed. Interrupt honored. Interrupt handler running, looking out, receiving more light from the laser far below.... a backdoor into the ship's code, installed when the newborn had subverted the humans' groundside equipment.... ... and the Power was aboard, with milliseconds to spare. Its agents -- not even human equivalent on this primitive hardware -- raced through the ship's automation, shutting down, aborting. There would be no jump. Cameras in the ship's bridge showed widening of eyes, the beginning of a scream. The humans knew, to the extent that horror can live in a fraction of a second.

There would be no jump. Yet the ultradrive was already committed. There would be a jump attempt, without automatic control a doomed one. Less than five milliseconds till the jump discharge, a mechanical cascade that no software could finesse. The newborn's agents flitted everywhere across the ship's computers, futilely attempting a shutdown. Nearly a light-second away, under the gray rubble at the High Lab, the Power could only watch. So. The frigate would be destroyed.

Localizers here we come! Vernor Vinge would be proud!

http://blog.regehr.org/archives/255

https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Localizers

Among the many uses of C is OS and Boot Loader programming, and in those cases the value "0" is still a valid memory address to use. IOW, there are some areas of programming where there is no invalid value. therefore you can't define what is non-valid and what is valid, therefore it is undefined. These areas are also a primary target of operation for the C Programming Language

The issue isn't that the behavior depends on the system it is running on. The issue is that modern compilers will aggressively optimize out any code that provably lead to undefined behavior, even when the programmer thinks he knows how the resulting code will run on his target system.

A better example of this is strict aliasing. Compilers have recently began taking advantage of the strict aliasing rules in the C standard, which has lead to a lot of previously working (but technically undefined) code recently breaking.

Stealing an example from the article linked above, the following code...

#include

typedef struct { int i1; } s1;
typedef struct { int i2; } s2;

void f(s1 *s1p, s2 *s2p) {
    s1p->i1 = 2;
    s2p->i2 = 3;
    printf("%i\n", s1p->i1);
}

int main() {
    s1 s = {.i1 = 1};
    f(&s, (s2 *)&s);
}
... leads to the following results:

$ gcc-5 effective.c ; ./a.out
3
$ gcc-5 -O2 effective.c ; ./a.out
2
$ clang-3.8 effective.c ; ./a.out
3
$ clang-3.8 -O2 effective.c ; ./a.out
3

Note the result for GCC with -O2.

C assumes you will choose an integer size that won't overflow in your application. If you don't, that's a bug, even if C provided the run-time ability to detect overflows. So making a run-time error the default behavior when it causes a measurable performance hit on most platforms (excluding MIPS and Alpha) doesn't really make sense in a low-level language like C.

Well, perhaps finding things to fix should be the job of static code analyser.

I saw Coverity made progress to detect Heartbleed-like bugs in OpenSSL.

I dunno. Coverity can catch a lot of stuff ... I don't know if it would have caught this, but it would be worth trying.

It was tried, and it did not catch it. Frama-C apparently would have caught it, but wasn't used.

I dunno. Coverity can catch a lot of stuff ... I don't know if it would have caught this, but it would be worth trying.

It was tried, and it did not catch it. Frama-C apparently would have caught it, but wasn't used.

There is a bug where memory is used after being freed which is hidden by the custom nonclearing LIFO freelist, i.e. you could realloc and get your record back.

Yeah, and that bug is unrelated to Heartbleed: heartbleed reads beyond the end of an allocation, and allocates a big enough allocation to store all that, and then sends it and frees the allocation. In its own little atom of horrible mishandling of program execution, it's fully consistent except for reading off the end of an allocation. There are no double-frees or use-after-frees causing heartbleed; the entire bug is a memcpy() that's too long.

Although "bug is a memcpy() that's too long" is technically correct (in a way), it's incomplete. Your lack of understanding of the implication of the "let's reuse that memory we just freed" in the whole heartbleed mess is appaling.

Thus the subverted the OSS benefit on 'many eyeballs" and did so ON SECURITY SOFTWARE.

You can read the code. Hell, a static checker found Heartbleed. That's the many eyeballs.

From that link you keep posting all around: "Coverity did not find the heartbleed bug itself" ... mind commenting ?

Bitch about this instead. A fucking static checker found heartbleed.

No, it says, "Coverity did not find the heartbleed bug itself", which very clearly means that Coverity did not find Heartbleed. And Coverity themselves confim that Coverity does not detect the problem (though in response, they've added a new heuristic that does detect it, but no word on how the new heuristic affects the false positive rate).

There is a bug where memory is used after being freed which is hidden by the custom nonclearing LIFO freelist, i.e. you could realloc and get your record back.

Yeah, and that bug is unrelated to Heartbleed: heartbleed reads beyond the end of an allocation, and allocates a big enough allocation to store all that, and then sends it and frees the allocation. In its own little atom of horrible mishandling of program execution, it's fully consistent except for reading off the end of an allocation. There are no double-frees or use-after-frees causing heartbleed; the entire bug is a memcpy() that's too long.

Thus the subverted the OSS benefit on 'many eyeballs" and did so ON SECURITY SOFTWARE.

You can read the code. Hell, a static checker found Heartbleed. That's the many eyeballs. And the whole argument about OpenBSD's fancy crap finding Heartbleed is fallacious: it would only catch Heartbleed on OpenSSL 1.0.1 on OpenBSD compiled with the freelist off and ONLY WHEN BEING ACTIVELY EXPLOITED. OpenBSD isn't exactly the most popular OS on production servers, and the protections in OpenBSD aren't widely implemented in allocators.

OpenSSL is broken in many ways. I dispute that the specific citations are technically correct: that unbreaking use of the system allocator would have made Heartbleed not happen; and that heartbleed was an allocation bug (this was alleged as a use-after-free early in this whole theater, but it's not; it's a validation bug, it reads too much, and it allocates an appropriate buffer of appropriate size to write to).

Look up freelists and object pooling. These design patterns are common and considered important. OpenSSL has MANY defects; use of a freelist isn't one of them, but inability to run on the allocator (for MANY reasons) is.

Let people swap the "fast" allocator back in at runtime, if you must. But make damn sure the code is correct enough to pass on "correctness checking" allocators.

If 100% of OpenSSL except those few lines in that one function were correct, OpenSSL would work on OpenBSD's allocator UNLESS being exploited, and even then it would be possible to extract some memory without tripping the protection. But, yes, the protection would catch an exploit. Normal operation? Nope.

The other side of that: most OS allocators don't have that protection, so in practice the vulnerability wouldn't get caught. And of course if it's in the wild, we have the situation we have today--this is not less-severe because it's shorter duration; you don't know if you were hacked, so you must assume your keys are compromised.

Bitch about this instead. A fucking static checker found heartbleed.

Coverity is a static analysis tool. It was tested on the source code with the Heartbleed vulnerability and did not find it. The developers of Coverity made a proof-of-concept modification to treat variables as tainted if they're subjected to endianess conversion, based on the assumption that such variables contain external and thus potentially hostile data. With this modification, Coverity finds the Heartbleed bug, as described in this blog post. Note the comment below the screenshot: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here." This may just be a consequence of not detecting all ways in which a tainted variable is sanitized, or it may point to more problems.

It's called "smart dust", and the idea is anything but new.

No. You are confusing dereferencing a null pointer, which is in fact undefined, with checking a pointer for null which is 100% defined.

No, I'm not.You, I think, are confusing removing the null check because it's a null check (which of course doesn't make sense) with removing the null check because it is never false.

But please, feel free to explain what specific part of the post you replied to is wrong. And maybe you want to also inform Chris Lattner (director of Apple's Developer Tools division and founding author of LLVM, which was the subject of his Master's and PhD theses) about how he is confusing dereferencing a null pointer with checking a pointer for null (immediately after "This would give us these two steps:" he shows the optimization that you're claiming I'm wrong about, though he doesn't explicitly explain it), and maybe also John Regehr (CS prof at the Univ. of Utah who does program analysis research) about how his explanation is also wrong (see "A Fun Case Analysis").

There's at least 191 kinds of undefined behaviour in C99. Its not reasonable to expect programmers to always perfectly avoid all of them.

We need compiler-writers to meet us half-way, by agreeing not to aggressively optimize out code that triggers undefined behaviour the way they are doing. There millions of existing time-bombs in billions of lines of C/C++ code out there, any one of which could suddenly become a serious problem when a new version of a popular compiler starts taking advantage of the fact that it is relying on undefined behaviour and optimizes it out, breaking code that used to work (even though that code was "incorrect"). Compiler writers need to be shamed into not doing this, because its a bad thing for everything and everyone except for their fucking benchmarks.

Everyone who cares about correctness of their C or C++ programs at all, should read carefully all of the following articles:

Dangerous Optimizations and the Loss of Causality (PDF)

Understanding Integer Overflow in C/C++ (PDF)

A Guide to Undefined Behavior in C and C++, Part 1 (blog post)

Finding Undefined Behavior Bugs by Finding Dead Code (blog post)

Then complain to your local compiler manufacturer. :P

Everyone who cares about correctness of their C or C++ programs at all, should read carefully all of the following articles:

Dangerous Optimizations and the Loss of Causality (PDF)

Understanding Integer Overflow in C/C++ (PDF)

A Guide to Undefined Behavior in C and C++, Part 1 (blog post)

Finding Undefined Behavior Bugs by Finding Dead Code (blog post)

Then complain to your local compiler manufacturer. :P

Yes, you didn't RTFA, because your definition actually makes sense. TFA defines "unstable code" as code with undefined behavior.

...and undefined behavior is exactly what causes the things I listed.

TFA also claims that many compilers simply DELETE such code. I have never seen a compiler that does that, and I seriously doubt if is really common.

You probably haven't used any desktop compilers.

Just a sampling:

• During MS's security push a decade ago, they discovered that the compiler was optimizing away the memset in code such as memset(password, '\0', len); free(password); that was limiting the lifetime of sensitive information, because the assignment to password in the memset was a dead assignment -- it was never read from (not actually undefined behavior, but it is an example of the compiler deleting unused code that was actually there for a purpose)
• I linked part 3 of this series to you in another response, but the first example in here discusses such an optimization that GCC did which removed security checks in the Linux kernel (see also this series -- look down at "A Fun Case Analysis")
• GCC has long turned on -fno-strict-aliasing because optimizations based on the strict aliasing assumption break the kernel (more precisely: code that violates the standard's strict aliasing rules was being "mis-"optimized), though I don't know if it led to security implications

Debugging quirks in the language? I don't know about Pascal, but it could be a lot worse than Java. At least the ints are always 32-bit.

Personally I would teach Lua, because of the dead simple syntax and good but not complicated feature set (the most complicated it gets is co-routines and meta-tables). Plus it's actually useful in the real world and is used in a number of apps.

C, predictable? Would you mind taking this http://blog.regehr.org/archives/721 quiz? It's about the predictability of integers in C.

Preventing downtime is an expensive, time consuming exercise, with few limits.

Before tackling the problem of downtime you should consider how much downtime is acceptable. See the discussion on downtime at the Uptime Institute regarding what is acceptable. Are you looking for 99.999% uptime? Dream on.

Specifically you need to make everything in your system redundant. The web servers need to be redundant, you need to have redundant copies of the data. The paths to the internet need to be redundant and the environment should be remote and redundant.

Once you get a handle on your environment, you should consider some sort of clustering technology for server duality. I suggest you read "In Search of Clusters" by Gregory F. Pfister to get a fundamental understanding of the technology.

As was posted earlier, you might just want to throw in the towel and accept web hosting. Use the Uptime Institute specifications against the ISP's service level agreement.

You might also consider a local ISP co-lo and do your own remote clustering.

Besides, how often has the publishing industry put out 'a new type of book.'

It's been almost eight years.

Assembly language poised for a revival? Wow, next thing you know people will discover how to emulate the working of a comuter using nothing but pen and paper.

I'm not sure if academics consider it a classic, but many will be interested in reading about the beginnings of UNIX: The UNIX Time-Sharing System, by Dennis Ritchie and Ken Thompson.

Thanks for the story. :)

Nonsense. In America, we don't have classes... in the sense of hereditary social strata. Take a look at the backgrounds of most corporate higher-ups and you will not find people born with a silver spoon in their mouths. Social mobility, which is very strong in America especially, gives lie to the term "classes."

BS.

Read "Class: A Guide Through the American Status System"
( Paul Fussell )
Informative Review
Review
Amazon.com, 4.5 stars

It's still one of my favorite short stories, and still sends a chill down my spine.

It was first published in 1957(!).

-a

In the context of this discussion, Asimov's The Feeling of Power makes for interesting reading. I recommend those who have not read it to look at it.

That reminds me of a great Isaac Asimov short story I read. "The Feeling of Power" is its title. Taking place in the not-so-distant future, people have become so estranged from basic mathematical abilities that they have not even dreamed it possible to perform mathematical calculations without their pocket computers. However, once a bored technician teaches himself to multiply numbers with only a pencil and paper, whole new possibilities in warfare are re-opened. Eventually, this technician commits suicide because of the disasterous results the discovery of what he thought was just a harmless hobby had. It's very satirical but illustrates how we are becoming increasingly alienated from the roots of the things we use every day.

You can read it for yourself at http://regehr.org/john/reading_list/power.html.

----

Nickie Haflinger has a unique talent: He's a phone phreak, someone who can manipulate the global data network using an ordinary veephone. And in a world where everything but the odd "paid-avoidance zone" is tied to the net, he's a dangerous man. More than one man, actually, since his ability -- combined with a pilfered high-level government code -- allows him to change identities at will.

A good deal of the time Science Fiction only gets part of the future right. John Brunner, at least in terms of the setting of the future, is very correct. His book foresaw the internet when most science fiction writers were still imagining big supercomputers acting as separate entities, programmed by tons of punch cards. However the pessimistic view he takes of the effect of this new future I find unbelievable. But then again, what do I know, this essay might have well caused someone to experience information overload :-)

To answer your question about tapeworms, in 1980 researchers at Xerox PARC dubbed the first self-replicating, self-propagating computer program a "worm", after the "tapeworms" Nickie used to erase his previous identities.

Hope this helps.