Slashdot Mirror
Magnitude of glibc Vulnerability Coming To Light (threatpost.com)
msm1267 writes: The glibc vulnerability disclosed this week has some experts on edge because of how DNS can leveraged in exploits. Dan Kaminsky said that while man-in-the-middle attacks are one vector, it would appear that it's also possible to exploit the bug and attack most Linux servers via DNS caching-only servers. 'This would be substantially worse if it went through the caching ecosystem; 99 percent of attack vectors go through that system,' Kaminsky said. Glibc, or the GNU C library, is used by most flavors of Linux and also a number of popular web services and frameworks, giving attacks potentially massive horizontal scale. The major Linux distros have patched and pushed updates to servers; source code is also available for homegrown Linux builds.
For being glib about it. (ba dump)
The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed since it requires more environmental factors to be a successful exploit.
Most likely organizations have much worse and easier exploitable vulnerabilities than this.
It's a shame most companies employ shitty, incompetent programmers who can't write software that doesn't contain buffer overflows.
A vulnerability that involves some aspect of DNS, prepare for APK spam, sadly no hosts files can block his advertisements for his software despite his claims it can block advertising.
Change is certain; progress is not obligatory.
Ummm...hello, Ada?
Still on DVL (https://en.wikipedia.org/wiki/Damn_Vulnerable_Linux), so I must be secure from this...
Where it gets really funny is... rust uses libc's dns resolver. Which is usually (always?) the buggy version from glibc.
Remember that when people ask why "we" don't rewrite all of libc in rust. I mean, if you want to, that's great. But maybe you should start in your own house. Meanwhile, musl and freebsd have much nicer libc implementations.
Personally, I'm not interested in rust. Not because of the language but because of the developers. I'm not sure if it's a programming language or an experiment in social justice gone wrong.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Those programmers are 'shitty, incompetent programmers' if they can't be bothered to learn about the problems their tools have. All tools have problems. It's their job to understand their tools.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
The problem with your theory is that essentially EVERY project of complexity more than "hello world" written in C has been shown to be a security nightmare.
Even the best programmers are unable to keep such minutia in their heads for a huge complex project. It is not a reasonable approach to expect a fallible human being to do by hand what the tool should do automatically.
Your opinion sounds just like the pilots in the 1940's who said, "The crashes due to pilot error are just due to bad pilots not remembering the checklists". But every else realized that is not how human brains work, and started making pilots read the checklist each and every time from paper, rather than try to remember it, and the accident rate plummeted.
It's long past time for the tech industry to get serious about security. We can't keep cowboying the shit out of things and hoping the same old approach will somehow produce different results this time.
A patch to a .so file is a great fix for most things... But, if you build your own statically linked executables please "make clean", "make"
Just a friendly public service reminder from the "Grey, but still alive"
0 it was patched before it became news :P
http://chimpbox.us
iptables -t raw -A PREROUTING -p udp --sport 53 -m length --length 28:2000 -j DROP
The above line will block any attack based on this vulnerability.
It may impact some unusual but legitimate queries, though. Normal DNS queries usually have small enough responses to fit in this range.
If the above line is on a Linux machine that is performing as a trusted caching DNS server, it will also protect the clients from the attack.
You might be able to get a few more bytes into the threshold (because there are headers in the DNS protocol) and I am not exactly sure where the overflow happens (raw packet, UDP payload, DNS payload, etc.). As a bonus, this will also drop unreasonably small packets.
It should be obvious that "compiles" and "doesn't crash" isn't the same thing as "works as intended"
It should also be obvious that the important data on a system isn't the operating system or anything else that can be re-installed. It is the user files, the things that are unique. Those are typically something that every program can access and delete at will.
This means that no high level language or no root/user separation will ever protect the things we care about the most.
If someone claims that a problem would disappear by using a particular language then you should probably not let them near anything important.
I wish schools would program more in low level languages and less in high level sandboxes.
What programmers need to learn is good programming habits and discipline.
When sloppy programming leads to an unwanted reboot you get good programmers that doesn't just modify and compile until it appears to work.
The "insecure" C functions that don't have the buffer overflow problems were replaced in C99, Anyone still developing against pre-C99 needs their faces slapped. Yes those _s functions have been around for ever, and Microsoft (despite pleading with users to switch to c++) have been warning against using insecure versions for a decade.
C++ isn't any better, and is in fact much worse for security since "secure" programming is about 100x slower (put and get functions) than just accessing the member variables with public.
If you want to get kids to program securely, you have to teach them C. Once kids understand what the underlying C library does, then teach them how C++ or Swift, or whatever else you want to teach is more secure than C by programming a certain way, and less secure than C by directly accessing variables.
No, it "only leads to other errors".
Funny, I haven't heard of any showstopper bugs in OpenBSD libc - not this year, not ever. And it's ubiquitous, since I'm running it on my phone.
This bug, after ghost, would be a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.
Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.
Good luck exploiting this bug.
Support my political activism on Patreon.
Yeah, I've found the Rust community to be very... odd.
I don't mean this in an insulting way, but I suspect that autism and/or Asperger syndrome runs rampant throughout the Rust community, to a degree far more severe than we see even within the wider IT and software community.
For example, they are extremely focused on achieving "correctness". This is something that's highly subjective, yet they try to come up with a one-size-fits-all objective definition. That's a common trait among those suffering from autism and Asperger's. They've ended up creating a language that meets their definition of "correctness", but that's otherwise very inflexible.
Their extensive code of conduct is another example of this. It's like they want to programmatically specify exactly how people should interact socially. Perhaps they're so focused on their CoC because, due to autism or Asperger's, they find normal social interaction difficult or even impossible? Of course, social interaction cannot be as strictly controlled and specified as they seem to want it to be.
It's also quaint how much emphasis they place on diversity, when nearly all of Rust's contributors are young white males. There's nothing wrong with that, of course. It's just that the extreme and unrelenting focus on diversity, despite a total lack of it, is a trait commonly associated with autism and Asperger's.
I've also noticed that they're extremely sensitive to legitimate criticism of Rust. Whenever Rust comes up at, say, Hacker News or Reddit or somewhere else where a lot of Rust's developers and users are, and somebody points out a flaw, the Rust supporters will attack that person. At Hacker News and Reddit this usually means the detractor, or even just somebody asking a legitimate but "wrong" question, will be severely downmodded. Sensitivity to criticism, and uncontrolled lashing out when subjected to criticism, are also signs of autism and Asperger syndrome.
I'd much rather deal with a programming language community that's actually diverse, and made up of relatively normal people, like the C, C++, Java, C#, and Python communities are. This leads to much more balanced languages, a more helpful community, and a better experience overall.
Jokes on you, DNS uses pascal-style length prefixed strings like SSL.
That's how we get attacks like heartbleed: "255A"
So the claim is that Rust isn't a systems programming language? Or is the claim that rust doesn't protect you from bugs like this? I'd say both claims are wrong.
It should be obvious that "compiles" and "doesn't crash" isn't the same thing as "works as intended"
True. In fact, even rust can crash under certain circumstances. For example, when the stack gets too large, or when a heap allocation fails. But all crashes of rust are "safe", meaning that they usually don't allow for data modification. And yes, rust doesn't guarantee freedom from bugs. But it does eliminate whole classes of bugs. On the path to more secure programs we do need languages with more additional safety, not less.
What programmers need to learn is good programming habits and discipline.
And the rust compiler enforces precisely those. Without enforcement (or warnings) you go nowhere. Rust's ownership concepts allows one to do multithreading without any fears. Consider a codebase with 500k lines and multiple threads: do you know when and how some thread accesses a shared resource? Most times not.
Possibly 0, because it was patched before it was publicized.
However, there are those out there who are able to independently discover and make use of these bugs before the rest of us. Whether they did or not will probably not be known until the appropriate information is declassified.
Who saw the name of the library, immediately went "oh, another C buffer attack," and rolled their eyes?
It's interesting how these things go.
If this would have been a vulnerability in MSVCRT, everyone would have mocked Microsoft and Windows.
However as this is a Linux vulnerability, the attention is turned to the used programming language instead.
Something to think about.
In the real world, getting work done means knowing the well understood problems with your tools. It's not like buffer overflows where not mentioned in everybody's introduction to C (course/competent self study). Explain to your boss that sanitizing inputs took to long, so all the tables in production got dropped...I hope you're 12 or at least don't code for living...seriously.
Thanks for volunteering to speak up for all the other shitty, incompetent programmers out there BTW. Way to jump on that grenade.
I'll grant you there are edge cases where tools are so shitty, you can't possibly know a tiny fraction of the serious problems. I'd argue those tools don't belong in production.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
We know its syntax is a step backward from C, C++, Java, C#, and even PHP.
Rust has many improvements over C/C++ syntax wise:
* syntactic macros, not "string replacement" macros
* scoped macros -- you don't pollute macro space
* scoped imports
* Nested comments -- no #if 0 trick needed to comment out code that contains block comments
* Blocks {} can have a return value, the ; sign is a separator, not a terminator
* If the compiler can find out the type of something, it is implied, otherwise you have to provide it. Only in recent C++ this is possible with the auto keyword.
Where is the "step backward" you talk about? Yes, they have abandoned the ? operator but that's no catastrophy, is it?
We know its resource management approach is confusing, even when you understand how it works and how to use it.
The resource management is in fact very useful, and I think the strong mutability requirements are a feature. I don't deny that sometimes its confusing, and that it contributes to rust's steep learning curve. But still, git has a steep learning curve as well, and there its certainly worth the effort, too.
according to its issue tracker it's really buggy
Yes, the repo counts 2302 open bugs, but they track feature requests in their issue tracker too. The actual bugs are much less.
We know there's only one implementation of it
Rust is a young language, and unfortunately there is only one implementation of it. Perhaps later on we'll get more implementations.
We know it took them fucking forever get Rust 1.0 out the door, and even then it wasn't stable.
Parts of rust are stable, parts aren't. If you use a release or beta channel rust compiler you only can use stable APIs. The fact that you see unstable features in the API docs as well is only to inform you what's upcoming.
We know that C++ has continued to evolve and can offer pretty much everything Rust offers.
You can write safe code in C++, but there is no guarantee. And C++ is promised to be backwards compatible. It has to support all the unsafe constructs that were introduced some day, most of them inherited from C. And yes, probably a C++ linter can do most of the job rust does as well, but as of now I haven't heard from a good free as in software linter that is as strict as rustc, and when you have to fix tons of linter warnings, you most times still have to basically do a rewrite of the program already. Then you can also rewrite it in rust.
We know that the Rust community is quite totalitarian, with an intolerant code of conduct and a mod team to take out anyone they don't like.
I agree, and think their "code of conduct" is very harmful to their project and makes people think that everybody who likes rust is an SJW. I claim to like rust and hate SJWs.
We question Mozilla's future
Mozilla is the biggest threat to rust's future, I agree. They had managed to publish a quite stable browser for ten years or so, but since 2014-ish they are acting weirdly, and this does impact rust negatively. I hope that rust will stay stable, and won't introduce breaking changes.
We ignore Rust because it just isn't a viable option!
Well yeah it isn't a viable option for super-big projects just yet, with less than one year of stability. Perhaps in five or more years rust has gained enough maturity and large enough support from the industry that its "too big to fail".
If this would have been a vulnerability in MSVCRT, it would be concealed as long as possible, and who knows when it would be fixed?
However as this is a Linux vulnerability, it was openly discussed and it was fixed at once.
There, FTFY.
Static executables use libraries too, they're just compiled in.
"First they came for the slanderers and i said nothing."
The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed
First, Heartbleed was actually a 5.0 base score, so this is more serious if you go strictly by CVSS score (which is not necessarily advisable). Reference.
Second, CVSS scores are based on a certain formula and small set of conditions; in particular, vulnerabilities are scored based on their immediate impact and not necessarily things that occur down the line. In other words, CVSS base scores do not include environmental metrics (There is a CVSS environmental score, but almost no one uses it except for CERT). So looking only at the base score is not always a good indication of severity; possibly its a good first approximation, but it's good to look into the details too. Since glibc is part of pretty much everything out there, this is a pretty serious issue.
And i don't mean the political ones. Libraries. And i don't mean the physical ones. Long live static executables.
I would think that if you have linked your binaries with libresolv.a instead of the dynamic libraries, you will continue to be at risk until all the binaries that do so have been rebuilt.
With dynamic linking, someone replacing the shared library only has to restart the binaries that still use the old library.
So no, I would venture that those that go the static route are somewhat worse off.
I would like to see your source code tracked through all its versions; and if you have one exploit or bad piece of code, off with your head.
Seriously people, it's not easy finding bugs,
If it was we'd have none. All software has bugs, it's just a matter of are they exploitable or not. It happens when you program in C and sometimes C++. Deal with it.
Your solution is even worse... I can easily replace a library that 10 programs are using because it's got a bug... Once that libraries routines are compiled into 10 programs... good luck finding those time bombs.
Yes Francis, the world has gone crazy.
Odd, I don't remember writing this.
I'm still an undergraduate student. I fully expect to be able to make a living in the industry though, and I intend to use whatever skills and time I have to educate as many people as possible about the massive fraud that is the open source "movement". It is time to take back programming from the narcissists and the amateurs
... says the person who just admitted he doesn't get paid to program.
The subject who is truly loyal to the Chief Magistrate will neither advise nor submit to arbitrary measures (Junius)
Where it gets really funny is... rust uses libc's dns resolver. Which is usually (always?) the buggy version from glibc.
Remember that when people ask why "we" don't rewrite all of libc in rust. I mean, if you want to, that's great. But maybe you should start in your own house. Meanwhile, musl and freebsd have much nicer libc implementations.
Personally, I'm not interested in rust. Not because of the language but because of the developers. I'm not sure if it's a programming language or an experiment in social justice gone wrong.
IOW: you are crazy.
In a perfect world where there are only super amazing developers such as yourself who never make any mistakes this is true. In the real world it's better to have a language that prevents dangerous errors like buffer overflows because most of us aren't a programming God like you clearly are.
However as this is a Linux vulnerability, it was openly discussed and it was fixed at once.
There, FTFY.
It was disclosed in July last year. That doesn't meet my definition of "at once".
https://sourceware.org/bugzilla/show_bug.cgi?id=18665
Don't worry, I'll work on the latter later. Right now I'm busy... uh... compiling. Yeah. I'm uh recompiling everything because of the glibc vulnerability. Yeah, I'll check in a progress report later.
This is the only employee you have left when you expect programmers to magically know about problems in other people's code just because they used that software as a tool.
Imagine expecting a factory worker, even an engineer working in a factory, to know the inner workings of the pick-and-place machine and predict all serious future bugs. It may even turn out that glibc has more lines of code to analyze and memorize than the pick-and-place firmware! And that is just one library. And when they start reading it, they'll realize they have to learn everything about the OS kernel so that they have the context to understand libc, and then they still don't understand it all because they have to consider the CPU implementation details, and all the motherboard subsystems. And the CPU probably has secret microcode, so you eventually just have to apply blind faith and trust an API when you get to the (fake) bottom! But there are actually still more turtles below you at that point.
All of that said, of course they're shitty programmers; all the applicants were humans. And according to various people with lots of letters after their names, the AI is even scarier. It makes sense when you realize that the "artificial" intelligence is actually human intelligence reduced to code and then left to free-associate.
If code-thrash continues to be common, and "bug-fixes" for non-security-related bugs are mixed together with security fixes and even new features, with a mono-culture system of a single "latest" version that contains all types of changes, then these bugs will never end. They will continue forever in that scenario. Luckily, eventually computers will not seem new, and so code thrash will not continue to be interesting or profitable.
Give it a few hundred years, things will settle out.
You might have an off-by-times-negative-one error in there, oops!
How can you preach about not making known C-language mistakes when you still make known English-language mistakes? Is it presumed that programmers have an easier time writing perfect C than writing perfect English?
If they stopped thrashing the code and put the new features in a new product, the existing product would reliably improve over time, regardless of what types of idiot mistakes they started out with. As long as the code is being frequently updated, it will have new bugs. Humans make mistakes, it is a fact and you are not immune. You are wrong to insist that it is somehow dysfunctional for humans to make known mistakes. Mistakes are the expected nominal condition!
How would they know to use C99, but not to switch to C17 or whatever comes in the future, that will doubtless have new bugs? And if they were using a clib from pre-C99... would it even be vulnerable to this bug? (no, it was introduced much later)
If the code is being continually updated, there is no escape from continually having new bugs and security holes. If you only fix real bugs, and don't add any features, then you still have new bugs in the fixes but the frequency will go down over time because less than 100% of new code is actually a bug, and so eventually the bug generation frequency would average less than a byte.
Automate catching a simple bug like buffer overflows and you leave developers too retarded to find the more serious memory map related exploits.
See also: Every Java only programmer you ever met.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
In addition to the problems with your comment already listed, I'd like to add that avoiding libraries would only mean pasting the code from the library into a single file before compilation. None of the code would be different in the non-library version, and so none of the bugs would be different either.
You could expand it to the more general solution, __FUCK_CODE, but where would you even define it?
Nobody is arguing about glibc. That's well understood to be a giant 'ball of mud', so nobody can know all it's problems.
We are arguing about the C language. To some extent the C++ language. AC in particular thinks knowing that unchecked buffer overflows exist as a class of exploits is too much to ask of C programmers.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
MS stopped being such a security concern once NAT came around then windows firewall as more of a standard apart from MSIE.
I operate the same way. I have a horrid time remembering proper nouns (e.g. people's names) but I remember functions, systems, relationships quite well. I use similar techniques where I rely on my analytical skills (which are quite strong) to get me through. I very frequently end up dancing around words I can't remember, substituting synonyms, descriptions ("your friend who we recently had dinner with", "the person in the red shirt"), and often use fillers like "thing", "stuff", "you know", or expletives. I always did awful on exams that required any sort of word recall where I had to provide terms from memory. If there was some sort of wordbank or terms were mentioned elsewhere in the exam I could describe their meaning/function; I have no problem recognizing words, just recalling them myself.
Oddly I have an exceptional memory for music. I can (or used to be able to) name the artist/song/album for thousands of songs, as well as the upcoming melody and sometimes lyrics. Many songs I can identify hearing only one or two notes (if it's the beginning of a song). I can identify many bands from only a few notes even if I'd never heard that particular song before. Many artists use similar sounds or styles at least per album if not for several so it's easy to recognize guitars tuned to a certain sound. My memory still fails a bit on specific band names, but not as bad as most proper nouns. If I can't recall the name I'm still able to provide a lot of associative data, e.g. they were popular in these years, they had these other really good songs that go "da da da", the lead singer is blind and gay, I saw them at an outdoor amphitheater and it was a beautiful evening--most people brought lawn chairs but we didn't think to, so eventually we rented some at the venue since even though we were on a hill our view was obstructed while sitting on the ground, and even though Muse was scheduled to play as an opener one of the members broke their toe so they couldn't come.
I don't recall having any head injuries as a child and wasn't told of any. It's possible I had a stroke as a baby and that damaged some parts of my brain, or maybe I'm "just different" due to genetics or some chemicals present during development. The closest thing I could find to describe it is some qualities of aphasia, which my primary care doctor said I definitely don't have. I recently went to a neurologist--half because I'm just curious what's up with me, half because I suck hard at interviews because it's very difficult for me to recall terminology even if I've used the technology for years--I just completely blank on the words. She also said I don't have aphasia and shouldn't worry about it being dementia/early Alzheimer's, since I've always been this way. Her only suggestions were I could get an MRI to see if I did have a stroke as a baby (for curiosity's sake, nothing would be done regardless of outcome) or go see a speech therapist.
I've never met anyone with similar problems so I'm glad you posted. I think it's strengthened my logic since I depend on it so much, and I definitely provide a unique perspective. People (the ones who give a shit, which are all I care about) seem to understand my way of speaking after they know me a while. I get a lot of confused looks from other people. I work around other things, like writing down shopping lists and grouping items by their location in the store. Or as a graduate student when I TA'd I'd plan out lessons in advance and have notes I could refer to during class. I had a lot of students give me great reviews and say I was the best TA (and one even said best teacher period) they had so far. But if someone randomly asked me some other time about any of the topics I taught, I really would not be able to communicate effectively or be much help. Unless they were willing to provide all the terms (if they even knew them), in which case I'd be able to stitch together a picture from my understanding. But otherwise it would be a lot of "that thing" and "you know", which is useless.
I'm not a morning p
I'm not sure you're going to get very far in your communications by insisting that the context is only idiotic off-topic language wars and not the actual context of the discussion.
You fail so hard, you don't even comment on what I said, you comment on what you said already, and yet you offer no clarification or correction.
Just presume I understand the context, and chose my words knowingly. You'll have a chance to understand my comments. What you're basically saying is that you can't understand my words, because I'm saying something different than what you said. To which I say, you failed to even try to understand me, so of course you didn't. I'll give you another hint: I wouldn't have wanted to say whatever you already said.
Yet another hint: language wars are so brain-dead, most of the programmers who respond to those threads will be discussing other points. Especially when the language-war is off-topic!
You are trying to change the subject in the middle.
Nobody can be expected to find all the bugs in a library they didn't have anything to do with writing. I won't defend a position you try to put on me and called you on the goalpost move.
Start a new thread if you want to start a new discussion.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Sorry wannabe bully, you're not going to chase nerds off slashdot by just signing up late and then telling us what to talk about.
If you can't figure out what story you're commenting on, that is not my problem; why would it lead me to change my subject?
You're off-topic, and complaining because my insights have a different focus than whatever you were saying. Get over it. I'm talking about the subject in the story, the same as almost everybody here. If you're talking about something else, that is on you. Don't try to blame it on me, and if you think telling me what to say has any chance to be effective, well. That is also on you.
Get off my lawn, kiddo.
The source to MSVCRT is distributed with Visual Studio - it would be pretty hard to conceal a vulnerability like this.
Last year we had two (Heartbleed and the Bash-bug), this year we had one (so far). I am affected by none of them. (My DNS-requests only go to my ISP and I am not afraid they will hack their clients - and yes, I did patch it anyway.)
Before that we had several years without any serious one.
IIRC, the only one that ever affected me was 2002 (or so?), the big SSH vulnerability.
In all other cases some special conditions were needed for the exploit that didn't apply to me (for example the Bash-bug didn't affect any of my servers because I don't run CGI and on top the default /bin/sh points to dash and not bash.)
However every serious Linux vulnerability is immediately going through the media - because it is so rare.
In the future, these bugs seem also increasingly unlikely because people immediately check the affected packages for security vulnerabilities (and AFAIK they also fixed a couple in bash).
You're right sir super genius. We shouldn't use computers for automation, that would be insanity. We should be programming them using two wires like God intended.
I wish I didn't have to agree with you. In fact the "speed" with which this was addressed is sufficient to yield some credence to those who believe that it was supported by those who have in other circumstances acted to intentionally weaken secure cryptography, and other secure systems.
I will grant that the evidence in support of this theory is so scant that accepting it counts as paranoia, but similarly it is strong enough that rejecting it counts as living in a fools paradise. As with many situations it the uncomfortable middle position of "well, maybe" that seems most supported by the evidence.
OTOH, it's never fair to rule out bureaucratic inertia. Which isn't, now that I think about it, a much more comfortable option.
I think we've pushed this "anyone can grow up to be president" thing too far.
Well, it's different from that, and both worse and better.
If programs all used static libraries, then there would be an indefinitely large number of versions of each library on each working machine, but each library would only be accessible to the programs that were compiled with it.
This would have the advantage that "breaking changes" wouldn't affect working code. And the advantage that different versions of, say, a browser would be likely to use different versions of each library. THIS would make it more difficult to write a strongly infectious virus, but more difficult to eradicate an existing one. (SOMEONE is going to continue running version myBrowser.x.y.z, so the virus is likely to never go away unless it's wantonly destructive.)
FWIW, the human immune complex has lots of different "library routines" compiled in, but as the system runs the immune complex changes its genetic code (via a cut and paste approach). This is designed to prevent humans from presenting a mono-culture for infections. It's not perfect, but it works pretty well. And this is analogous to something that could be done with static libraries. I'm not really sure, however, that the systems are otherwise sufficiently similar that this would work on current computer systems. It does resemble having a set of virus checkers running in background threads all the time, but there are enough differences that...well, my best estimate is that running a closely analogous system would be so expensive that you couldn't do anything else.
I think we've pushed this "anyone can grow up to be president" thing too far.
And it took 7 years to discover the bug. This is not a win for OSS security. Couple this with heartbleed and it's been a horrendous couple of years for trust of OSS code review.
Speaking as someone who actually uses C++, and who does understand object orientation....
C++ is far better. You can avoid buffer overflows by never using C-style arrays except in interfaces. Use std::string and std::vector and the other container classes, and use .at() instead of [] if your compiler doesn't offer checked [] (.at() is required to be range-checked, while [] may or may not be). Since these are templates, they're very fast. std::sort is normally faster than C's qsort().
C++ has far better memory safety, by using smart pointers. std::shared_ptr does slow down performance, but std::unique_ptr doesn't.
If you have a decent optimizing compiler, get() and put() are about as fast as direct access. If you don't have a decent optimizing compiler, get() and put() are not anywhere near your biggest performance problems. Not to mention they're almost as bad as public variables for encapsulation, one of the bases for object-oriented programming, and should not be used unless modifying that member variable does something meaningful in terms of using the class rather than just exposing implementation details.
C++ has problems of its own, but for the simpler stuff it's much safer than C.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Having static everything would certainly prevent a virus making use of libraries from infecting every process, but that isn't necessary or even desirable to them. Having more different available versions to attack would increase the likelihood of infection. But more to the point with these exploits is attacks generally, not the special case of viruses. If somebody is attacking a system, they're going to attack all of the available surface until they get in, and then stop. Having all those different library surfaces makes it more difficult to predict which attack will succeed, but it makes it more likely that one of them will.
Any immune response that you build is going to either be very limited in functionality, or else an additional attack vector. If you want a bunch of small processes running, each of which might kill another process because it thinks it is misbehaving, you might eventually build a system that responds in a similar way to attack; but it would also have things like allergic reactions, where false positives destroy existing functionality and data. You would have to completely give up repeatability and the ability to predict behaviors; even ones you're programming. And testing would never guarantee continued functioning, even without code changes.
Not every paradigm from nature is going to be applicable to human computing tools.
Most viruses/exploits target a particular library running in the context of a particular application. This would fragment their ecosystem. And vaccinations against particular diseases (AKA binary patches) would be possible...but they've be very version dependent.
You're right, not every paradigm is going to be applicable, and I thing, after making due allowances for metaphor translation, this one would be too expensive. But the proposal isn't ALL bad.
I think we've pushed this "anyone can grow up to be president" thing too far.
I say that it is a young language that still has to get maturity and trustability. Right now its a perfectly fine base to build something upon, but with less than one year of stability, I _do_ admit that probably you shouldn't invest millions of dollars into writing programs with it.
Most viruses/exploits target a particular library running in the context of a particular application.
That has a lot to do with the historical way that applications are linked, though. If applications were commonly linked against different libraries, there would be a lot more fuzzing and things going on. The nature of the exploits would be different than they are.
Targeted attacks already use the techniques that would be more common in that alternate world.
The proposal isn't all bad; it may or may not even be bad, generally. But since it wouldn't be able to achieve what it claims, it is more likely harmful that helpful, the same as any random mutation.
It is already fairly normal to spam all inputs with malformed SQL :) My logs are usually filled with it, anyways, on most services. I also see various string overflows being tried on any input.
From a technical perspective, it is not likely to make much progress on these problems at the same time as wanting to constantly "innovate" and have new features. Once people figure out what features they want from computers, then a serious effort to write solutions that won't require constant change can begin. If you don't have code thrash, any of these linking paradigms can eventually reach a state of very few bugs, and very little attack surface.
There are many programming languages, perhaps C and assembler just aren't for you. Stick with LOGO.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
What happened to you APK? Did you lose Internet for a few days or something?
Change is certain; progress is not obligatory.