The narrative keeps changing. The first pass I heard was ffmpeg was full of NIH, haphazard bullshit, retard babies, and idiot politics, with code quality going down the shitter, hence the fork to libav; the latest pass I heard was ffmpeg folds in all the important features and bugfixes libav makes, while libav goes all NIH and re-implements their own from scratch, often simply ignoring bugs because it's run by a development team of retard babies and driven entirely by idiot politics.
What was the point of putting "obviating" in quotes there? It makes you sound like a retard who's looking down his nose at someone for using a specific word you don't fully understand.
My OS only updates when I want it to. Cyanogenmod comes built that way. Some danger from Google Play or Amazon App Store, which can install whatever they want.
Security is hard. I can still install a bad application, or have Google Play update itself with nastiness; I can also remove those things and not install updates. It's a similar problem when the phone's whole OS has a built-in auto-update, although you can't just rip that out; then again, modified Android OSes *are* just ripping the OS out.
That's what I'm thinking. That's $1,300/month, and I was spending under $1,000/month in Baltimore. I'm spending even less now.
My Citizen's Dividend plan can do it in about $550/month in 2013 (it'll be ~$598 in 2016), but that relies on market force: food, clothing, personal care, all current; single-inhabitant 224sqft apartment requires modification of currently-uninhabited structures in low-income areas. It would take a few years for the landlords to shuffle enough money around to transition the 600,000 homeless into apartments, never mind the 4.8 million from HUD into income-appropriate housing (which, for a family, includes at least *two* incomes, and so can provide a profit motive for a larger unit).
That kind of income level isn't viable for the existing market; but $1,300/month? Uh, yeah. You're just trying to live in rich-folk land on poor-folk money.
Not really. Out-of-bounds errors would only occur if you intentionally gave the library bad data. Theo's argument was OpenBSD's malloc() would immediately catch an out-of-bounds *read*, but it can't do that without consuming geometrically more memory--the average size of a malloc() allocation is under 200 bytes, and OpenBSD would need to right-align all allocations in an isolated 4096-byte page to do the kind of trapping Theo asserts, meaning something like Firefox would consume around 20GB of physical RAM instead of 1GB. What OpenBSD actually does is allocate miniature heaps with gaps between them, limiting the size and scope, but utterly failing to catch any off-by-1 errors or other likely candidates for exposing an OpenSSL bug like Heartbleed.
In other words: you *could* catch it with Valgrind or OpenBSD if you both already knew about the Heartbleed bug *and* intentionally triggered it. If you ran OpenSSL against normal, non-malicious requests, it wouldn't misbehave; and even a slightly-erroneous request wouldn't necessarily step across the 16-byte word-alignment barrier that the allocators use (i.e. you allocated 27 bytes, you need to write at *least* 6 extra bytes before you're past the 32 bytes of your allocation).
The chances of this actually happening are near to zero. OpenBSD announced they found a constantly-triggered overflow bug in X11 after some 30 years, and they've had their current protections for well over a decade leading up to that. The problem was it *usually* only wrote *one* byte past the end of the buffer; when it wrote an extra 20 bytes in one case, it triggered a crash, and somebody took notice of the crash report. It probably wasn't the first time that happened, as it's unlikely the first person to experience an X crash bothers to look at the logs (unless it keeps doing it).
So yeah, maybe OpenBSD would have caught Heartbleed some time in 2029 if it had used malloc() *and* nobody discovered it otherwise.
Why would I simply throw away glasses I could get a few more uses out of? I drive a 2004 Mazda 3; should I get a new car because third gear's been broken for 2 years?
The shit you've been babbling about is more vapid than anything on YouTube.
It's an information thing. Creativity is derived from inventory of the brain's contents and the abstract association of various bits of memory. Had you understood that, you might have drawn several tangential ideals from everything I've said; instead you think like a brick.
I simply assumed the glasses were shit, and stopped using that type of glass after they all broke. It's the same principle behind never using perl.
I can inform you right now that your hot water heater is not adjusted to specification, and you failed to expect to need to adjust your washing technique to mitigate that.
You seem to have not noticed it didn't burn my hands.
the nuclear containment building is not a viable metaphor for the type of code mitigation strategies you describe.
It limits the scope of damage without preventing the actual precipitating event. C buffer overflows no longer allow remote code execution, but rather cause denial of service. With privilege separation strategies, you use a non-privileged daemon to sendmsg() a file handle (e.g. TCP connection) to a privileged daemon, which forks off and chroot()s a non-privileged daemon, which then interprets the data, then uses sendmsg() to send the connection and instructions to a privileged daemon, which then switches to the appropriate user, and suddenly sshd is never interpreting a login event as a privileged user. With sandbox strategies, you might do the same, chroot()ing a worker and then using sendmsg() to give it a connection, exchanging processed data with it. Either way, hack these things and you get... nothing useful. Even in an exploit condition, the damage is contained.
We built a lot of crap around things that could break, and they only break that bad. They break *really* *bad* when they break, but we put a wall around them and so they're contained.
And python code does not have less bugs, that is an inanity with a known value.
Python code doesn't have the same number of remote code execution bugs as C code. It has distinctly fewer remote code execution bugs per thousand lines of code. This is because causing remote code execution in Python is really freaking hard, since you don't spend a whole hell of a lot of time directly manipulating pointers to fixed-size memory areas or doing *anything* *else* that can affect program execution flow outside the boundaries of intent.
Dishwashers aren't dangerous per se. It's just that cheap soda lime glass does crack when heated. I've had glass mugs explode in my hand while hand-washing: when pulled out from under the faucet, the cool air caused the glass to contract and crack, sometimes loudly, sometimes energetically. I lost *six* mugs in a set that way, the type made of green-tinted glass that's not thermally stable at all. If you open a dishwasher while the same type of glass is still hot, you expose heated glass to cool air; leave the dishwasher closed and the air inside cools slowly, preventing breakage. Many modern dishwashers include passive circulation facilities which allow the heated, humid air to rise and flow out a rear vent, drawing cool, dry air into a lower vent through a counterflow exchanger, thus retaining the warmth of the leaving air but ejecting the humidity, effectively drying the dishes--and thus they recommend leaving the dishwasher closed for 30 minutes to allow a passive drying cycle (no fans!).
How can systems that want to "keep up" possibly avoid repeating these mistakes, or other new ones if you achieve a best practice that prevents the old one?
You don't avoid them; you mitigate. Avoidance is using C# or Python to eliminate the possibility of coding a buffer overflow and creating a route for native code injection. W^X, PaX, ExecShield, stack smash protection, and other types of execution environment and code generation protections instead surround dangerous code with facilities to react to their flaws.
That is to say: you can still inject code into the application; you just can't get the application to actually *execute* that code. Your program flow is still trashed, your program still crashes, and your system still suffers some kind of loss of service; this loss of service is of a lesser severity than what the same programming mistake would normally cause (e.g. a program crash instead of a remote shell; remote access to a zero-privilege user instead of remote root access).
It's the same reason we build containment buildings around nuclear reactors. The damn thing might melt and vent radioactive dust and gas into the containment building, but that's significantly less bad than venting it into the open atmosphere. You get a massive economic injury instead of the same economic injury *and* an enormous ecological disaster.
As for new mistakes, technology advances when new mistakes become less frequent or less severe. You can still fuck up by the numbers in C#; it happens much less often, and the result is usually not so spectacular. Usually you have to mishandle authorization control, such as by creating an SQL injection allowing the remote user to obtain database privileges (the application presents certain operations to the user, and uses a database account whose set of possible operations encompasses those end-user operations; if the user can insert arbitrary SQL code, he has access to *all* operations the application can perform). Accidentally screwing up your program in such a way as to allow arbitrary flow control redirection is *really* hard in C#.
The whole thing is bullshit-on-hold. I already know the narrative; I've modeled the current government in abstract from bits and pieces I've picked up while not really paying attention.
You want to know how it plays out?
The government cracks the phone. It finds evidence of the shooting on there--possibly explicit, possibly vague. Regardless, it's evidence. They hold up this evidence and say, "If this hadn't been encrypted, we could have stopped this shooting!"
That's contingent on them actually cracking the phone, but it's the direction they're going. Notice the huge flaw in logic: They weren't in possession of the phone pre-shooting, and any software on the phone would be able to bypass the encryption. Network monitoring would have given them any unencrypted information. Encrypted messaging is a different facility, and any systems to look for certain key words would face both an incredible wall of false positives and misdirection by simple codes ("did you remember to pick up eggs?" "I'll buy them tonight around 8." Shooting is at 8pm). Doesn't matter; the narrative is swallowed by the masses, because people in groups don't think.
I doubt they'll fabricate evidence and claim they broke the encryption. They may be using this case as pressure, hoping to bring multiple such cases forward and continuously claim people are dying because of encryption. That's more conjecture; I'm pretty firm on their political play at the masses, but not on the power buildup via repeated demands for backdoor decryption capabilities through multiple tragedies. My models give me movie plots, but not firm projections; more data will elevate some of those movie plots to firm projections.
Just watch when they *do* break someone's encryption in one of these cases. Watch what they say after. They'll spin a narrative about how the encryption allowed the crime to occur, about how they could have stopped it if only there was an encryption back door.
It's the politics part that usually applies. The strlcpy() thing cited is politics, just not governmental politics.
I've had three arguments with Theo. The first was over his claim that position-independent executables were "very expensive," which I responded to by benchmarking the entire execution of a Linux OS and determining that the system would indeed slow down if it couldn't find 4 seconds of CPU idle time out of each day (the hit was 1% or 6%, depending on optimization; but the proportion of time spent in main executable code was 0.018% of all execution, since everything happens in libraries). The second was an argument over whether static checking was useful, in which Theo claimed a tool like Coverity PROTECT would *decrease* code security (OpenBSD now uses Coverity PROTECT to look for vulnerabilities). The third was a buck against his analysis of OpenSSL's Heartbleed vulnerability, which he claimed was vulnerable due to the use of an internal ring buffer allocator rather than malloc(), instead of by virtue of not performing bounds checking (there were *several* points he was wrong on).
Ulrich Drepper argued with Michael Meeks about a lot of dynamic-link-time optimizations, then huddled down for a month and released the same code with his name slapped on it. He's got a history of NIH and of stuff like you see with strlcpy().
All of these things are political battles. Theo's issue with PIE was that PaX and GRSecurity were pushing PIE, and he didn't think about that for W^X; his issue with Coverity was that he'd been loudly proclaiming OpenBSD is perfect and secure, and mocking other projects for having all these holes; and his main attack on OpenSSL was basically a large claim that we'd have seen Heartbleed coming if we used OpenBSD malloc() (again: OpenBSD will save the world!). Drepper similarly is trying to prove the universe revolves around him.
These are people who wrote operating systems, or significant parts thereof. They say and do really fucking stupid things, constantly; they've got one good trick and a huge padding of wargable. If you watch, you'll see they screw up technical concepts they should know dead cold because they're more focused on politics.
It's not really binary. Humans are complex, and that complexity gives you about a billion ways to prove you're an idiot. This works so well that you can have genius-level skill in a highly-complex discipline and still be an idiot *within* *that* *discipline*. Matthew Garrett occasionally accuses Linus Torvalds of this, and not just because he's butthurt about being associated with Microsoft Blowjobs.
This is all true; and yet the media machine dismisses all denial-of-service attacks, all bugs that just crash your application, and instead jump up and down with white sheets making spooky noises whenever they see the words "Remote Code Execution." The report here is that glibc has this huge, terrifying attack surface turning any application into a hacker back door paradise; that assessment is false.
Did you hear about CVE-2015-1473, allowing a local or remote user to trigger a denial-of-service in glibc? What about CVE-2014-6040, the iconv() denial-of-service causing a crash in glibc iconv(), which converts between encoded 8-bit text e.g. Windows smart quotes, ASCII standard, and Latin-1? Good places to throw HTTP requests that absolutely murder your Apache2 web server. CVE-2014-8121, glibc infinite loop in nsswitch facilities, lets a remote attacker make glibc perform a look-up while already performing a look-up, repeatedly resetting the file pointer forever.
Nobody really cares all that much. "Hackers can take over the entire Internet!" is a better headline.
Among those, many of the techniques you've provided require the ability to write to arbitrary memory locations (in which case you can use *that* bug to emulate *this* bug, so no change). Some rely on Windows Safe Exception Handling exploits. One of the methods given is "attack a function that isn't protected", which is a handwave.
The phrack article has a program exploiting itself by inspecting its own memory space and then jumping over terminator canaries. That is: rather than strcpy(buffer, baddata), it strcpy(buffer+offset, baddata). In practice, this means having a way to change the strcpy() call's target--i.e. a way to write arbitrary data to arbitrary memory. The other attack overwrites the shadow pointers, which is another write-anything-anywhere style attack. Both such attacks can fully emulate *this* bug, and so would provide the same capability of exploitation of this bug. In other words: no new risk introduced by this bug.
Core's article is the same: can write to arbitrary memory locations.
Notably, the address space randomization protection would obfuscate the location of the retarray used in StackGuard, making such attacks more difficult in the same way previously stated.
In any case, all of these are ways to get around randomized canaries. They all require the ability to write to arbitrary memory, which gives you a bigger tool to perform a much broader attack. This doesn't defeat address space randomization; and address space randomization doesn't defeat having all memory be exclusively writable OR executable (meaning injecting code flat out doesn't work, even if we hand you all the keys to do so).
Think about that. In 1998, a simple overflow like this would be a quick way to exploit anything on a whim; now it just means that, if you slit the throat of a virgin goat and bathe your naked body in its blood under the light of a full moon on Winter Solstace when the planets are in alignment, you have a 1 in several billion billion chance of crashing the program due to an attempt to execute the stack, instead of crashing it due to a bounds check.
You comment about dishwashers using hot water, but not about glass that can handle sudden temperature differentials?
I'm being realistic. It's like saying you can't do any banking on the Internet because someone could steal your credit cards when you log into your bank site; that worked in 1990, but we've since started using SSL and 128-bit encryption. Banking is safe, and running around screaming that the packets go through a bunch of routers in between and someone might be able to read the data is just wargarble.
To say that this vulnerability is as big a deal as it's made out to be would require you to also acknowledge that ever logging into any banking site, ever, or using any credit card on the Internet would require immediately canceling that card and those accounts because someone has probably stolen them as soon as they went on the wire.
Anti-virus software is an arms race. This is a change to the fundamental behavior of the compiler toolchain and produced code.
Think like someone tells you dishwashers are dangerous because they use high-temperature hot water, and then your glasses all crack because they drop from 145F as they're exposed to the cold air when you open the door after a wash cycle. You then point out that your glassware is all borosilicate glass and can take a temperature drop of 120 degrees celsius across 1 second without damage. Going from boiling to ice water won't break your glass; heating it dry over an acetyloxy torch and then dumping it in an ice bath *will* shatter it.
What you're looking at here isn't a system that catches one specific attack signature. You're looking at an attack which fundamentally relies on overflowing a buffer on the stack, rewriting RETP with an address on the stack that contains code injected as part of the overflow, and then jumping into that code on RETL instruction. This executes your code from the stack.
Meanwhile, the software being attacked stores a runtime-randomized word between the stack variables and RETP, then verifies it hasn't changed before a call to RETL, so you have to guess a 32-bit or 64-bit integer (1 in 4 billion or 1 in 16 billion*billion). If that fails, the system *still* has randomized the stack base, so you have to load a value into RETP which points to your code on the stack, which can be in any of thousands or millions of locations. Should you manage to guess both a one-in-four-billion and a one-in-524-thousand value simultaneously (one-in-2251-billion-billion) (or bigger on 64-bit), the stack is still non-executable: the OS will claim a general protection fault due to trying to execute non-executable memory.
That means this attack can't be carried out successfully without extreme luck (1 in 9.7 billion billion billion) or advanced knowledge of the program's address space (which the attacker must inspect while the program is running--it changes on every run); and even then, the attack has to do something distinctly other than injecting code. Heap, main executable, and library load addresses are also randomized on each run, so luck in dodging out the primary protections leads directly to rolling bigger dice in hopes of getting lucky a third time.
In this particular attack, you can't just launch an attack at a target. You have to gain control of DNS responses for that target, then wait for the target to make a DNS query. All of the above then apply. Good luck.
Ulrich Drepper is an idiot. So is Theo da Rat. They're like rednecks who can fix absolutely any automobile you bring them, but are too stupid to think beyond the end of a wrench; these rednecks just know how to write C.
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.
Ok first when you use quote marks it means you are quoting. This is not a quote so is false.
Right, because it's not like quotation marks are routinely used that way in millions of books, papers, news articles, and other English language materials. Look, kid, maybe when you start reading, you'll learn about indirect quotation and its use in modern English.
No one claimed this was a solution for all of Europe, yet this was your argument.
Well at the scale given, it's not useful for exporting power to Europe--which seems to be the plan. Any significant supply of European power is going to need a large land area.
You argued that the land could be better for habitation and food production,
No, I didn't. We've covered this, Timmy. I issued comparisons for scale and also described the scale of land usage when trying to provide power via solar. For a block of land including living space and solar power generation, 72% of the land goes to solar power and 28% is living space. See the below:
to go all-solar at this efficiency, 72% of the land must be solar, assuming densely-packed apartments filled with families (New York apartment projects).
I also said this:
That space of land could feed over 6,000 people [farmlandlp.com] if properly arable
You see, 6,000 acres of land is... what? It's uh. Some feet. And square feet.... how big is that in bananas? What *is* 6,000 acres of land? Is it bigger than a square cubit?
Answer: 6,000 acres of land is the same size as an area of arable farm land which feeds 6,000 people for one year.
Let's examine another quote, one that will benefit you greatly since you dropped out of school before second grade:
An analogy is a comparison in which an idea or a thing is compared to another thing that is quite different from it. It aims at explaining that idea or thing by comparing it to something that is familiar.
So to answer your question:
You made the claim that solar would use up our food producing land (see the quotes of your own words above), and this was the claim that was argued against (ie it's not using food producing land, as shown in the TFA). Do you understand now?
No, I didn't make the claim that solar would use up our food producing land. I made analogies, and drew scale between living space and the solar power production space needed to produce electricity for that space. By the way, THREE FUCKING TIMES AS MUCH LAND AREA devoted to solar to supply power. For the land needed to house 400 people, you need to install solar panels across the land needed to house 1,200 people in order to give them solar-based electricity. That's also analogical; remember that *analogies* are inherently *comparisons*, so you should be able to do this magical thing that intelligent people do called *visualization* and get a direct grasp of scale of solar installation.
Or you could continue being a deceptive worm and try to get people to juggle numbers without reference in their heads, hoping they don't understand what those numbers mean in real-world terms.
Slashdot Mirror
Intention doesn't indicate reality. Bitcoin isn't even a currency; it's a commodity and, like gold, makes a terrible currency.
The narrative keeps changing. The first pass I heard was ffmpeg was full of NIH, haphazard bullshit, retard babies, and idiot politics, with code quality going down the shitter, hence the fork to libav; the latest pass I heard was ffmpeg folds in all the important features and bugfixes libav makes, while libav goes all NIH and re-implements their own from scratch, often simply ignoring bugs because it's run by a development team of retard babies and driven entirely by idiot politics.
$1 million in $100 bills weighs 5 pounds; $1 million in $100 / 5 bills weighs 5 * 22 pounds.
Commodities make bad currency.
What was the point of putting "obviating" in quotes there? It makes you sound like a retard who's looking down his nose at someone for using a specific word you don't fully understand.
My OS only updates when I want it to. Cyanogenmod comes built that way. Some danger from Google Play or Amazon App Store, which can install whatever they want.
Security is hard. I can still install a bad application, or have Google Play update itself with nastiness; I can also remove those things and not install updates. It's a similar problem when the phone's whole OS has a built-in auto-update, although you can't just rip that out; then again, modified Android OSes *are* just ripping the OS out.
It makes for good television.
What r-tard pays 80% of their income into housing?
He says it didn't come up to him. Can't prevent what you don't know is happening.
That's what I'm thinking. That's $1,300/month, and I was spending under $1,000/month in Baltimore. I'm spending even less now.
My Citizen's Dividend plan can do it in about $550/month in 2013 (it'll be ~$598 in 2016), but that relies on market force: food, clothing, personal care, all current; single-inhabitant 224sqft apartment requires modification of currently-uninhabited structures in low-income areas. It would take a few years for the landlords to shuffle enough money around to transition the 600,000 homeless into apartments, never mind the 4.8 million from HUD into income-appropriate housing (which, for a family, includes at least *two* incomes, and so can provide a profit motive for a larger unit).
That kind of income level isn't viable for the existing market; but $1,300/month? Uh, yeah. You're just trying to live in rich-folk land on poor-folk money.
Put it on the Internet, then took it down. They pirated my album... SO I PULL OUT MY GUN!
Not really. Out-of-bounds errors would only occur if you intentionally gave the library bad data. Theo's argument was OpenBSD's malloc() would immediately catch an out-of-bounds *read*, but it can't do that without consuming geometrically more memory--the average size of a malloc() allocation is under 200 bytes, and OpenBSD would need to right-align all allocations in an isolated 4096-byte page to do the kind of trapping Theo asserts, meaning something like Firefox would consume around 20GB of physical RAM instead of 1GB. What OpenBSD actually does is allocate miniature heaps with gaps between them, limiting the size and scope, but utterly failing to catch any off-by-1 errors or other likely candidates for exposing an OpenSSL bug like Heartbleed.
In other words: you *could* catch it with Valgrind or OpenBSD if you both already knew about the Heartbleed bug *and* intentionally triggered it. If you ran OpenSSL against normal, non-malicious requests, it wouldn't misbehave; and even a slightly-erroneous request wouldn't necessarily step across the 16-byte word-alignment barrier that the allocators use (i.e. you allocated 27 bytes, you need to write at *least* 6 extra bytes before you're past the 32 bytes of your allocation).
The chances of this actually happening are near to zero. OpenBSD announced they found a constantly-triggered overflow bug in X11 after some 30 years, and they've had their current protections for well over a decade leading up to that. The problem was it *usually* only wrote *one* byte past the end of the buffer; when it wrote an extra 20 bytes in one case, it triggered a crash, and somebody took notice of the crash report. It probably wasn't the first time that happened, as it's unlikely the first person to experience an X crash bothers to look at the logs (unless it keeps doing it).
So yeah, maybe OpenBSD would have caught Heartbleed some time in 2029 if it had used malloc() *and* nobody discovered it otherwise.
Why would I simply throw away glasses I could get a few more uses out of? I drive a 2004 Mazda 3; should I get a new car because third gear's been broken for 2 years?
The shit you've been babbling about is more vapid than anything on YouTube.
It's an information thing. Creativity is derived from inventory of the brain's contents and the abstract association of various bits of memory. Had you understood that, you might have drawn several tangential ideals from everything I've said; instead you think like a brick.
I simply assumed the glasses were shit, and stopped using that type of glass after they all broke. It's the same principle behind never using perl.
I can inform you right now that your hot water heater is not adjusted to specification, and you failed to expect to need to adjust your washing technique to mitigate that.
You seem to have not noticed it didn't burn my hands.
the nuclear containment building is not a viable metaphor for the type of code mitigation strategies you describe.
It limits the scope of damage without preventing the actual precipitating event. C buffer overflows no longer allow remote code execution, but rather cause denial of service. With privilege separation strategies, you use a non-privileged daemon to sendmsg() a file handle (e.g. TCP connection) to a privileged daemon, which forks off and chroot()s a non-privileged daemon, which then interprets the data, then uses sendmsg() to send the connection and instructions to a privileged daemon, which then switches to the appropriate user, and suddenly sshd is never interpreting a login event as a privileged user. With sandbox strategies, you might do the same, chroot()ing a worker and then using sendmsg() to give it a connection, exchanging processed data with it. Either way, hack these things and you get ... nothing useful. Even in an exploit condition, the damage is contained.
We built a lot of crap around things that could break, and they only break that bad. They break *really* *bad* when they break, but we put a wall around them and so they're contained.
And python code does not have less bugs, that is an inanity with a known value.
Python code doesn't have the same number of remote code execution bugs as C code. It has distinctly fewer remote code execution bugs per thousand lines of code. This is because causing remote code execution in Python is really freaking hard, since you don't spend a whole hell of a lot of time directly manipulating pointers to fixed-size memory areas or doing *anything* *else* that can affect program execution flow outside the boundaries of intent.
It has other, less-important bugs.
Then you restrict your access to information, and have no way to analyze the technical merits of any point anyway.
Pejorative puns are fun, especially when you can mix in a or two. I suppose you wouldn't understand the creative process either, though.
Dishwashers aren't dangerous per se. It's just that cheap soda lime glass does crack when heated. I've had glass mugs explode in my hand while hand-washing: when pulled out from under the faucet, the cool air caused the glass to contract and crack, sometimes loudly, sometimes energetically. I lost *six* mugs in a set that way, the type made of green-tinted glass that's not thermally stable at all. If you open a dishwasher while the same type of glass is still hot, you expose heated glass to cool air; leave the dishwasher closed and the air inside cools slowly, preventing breakage. Many modern dishwashers include passive circulation facilities which allow the heated, humid air to rise and flow out a rear vent, drawing cool, dry air into a lower vent through a counterflow exchanger, thus retaining the warmth of the leaving air but ejecting the humidity, effectively drying the dishes--and thus they recommend leaving the dishwasher closed for 30 minutes to allow a passive drying cycle (no fans!).
How can systems that want to "keep up" possibly avoid repeating these mistakes, or other new ones if you achieve a best practice that prevents the old one?
You don't avoid them; you mitigate. Avoidance is using C# or Python to eliminate the possibility of coding a buffer overflow and creating a route for native code injection. W^X, PaX, ExecShield, stack smash protection, and other types of execution environment and code generation protections instead surround dangerous code with facilities to react to their flaws.
That is to say: you can still inject code into the application; you just can't get the application to actually *execute* that code. Your program flow is still trashed, your program still crashes, and your system still suffers some kind of loss of service; this loss of service is of a lesser severity than what the same programming mistake would normally cause (e.g. a program crash instead of a remote shell; remote access to a zero-privilege user instead of remote root access).
It's the same reason we build containment buildings around nuclear reactors. The damn thing might melt and vent radioactive dust and gas into the containment building, but that's significantly less bad than venting it into the open atmosphere. You get a massive economic injury instead of the same economic injury *and* an enormous ecological disaster.
As for new mistakes, technology advances when new mistakes become less frequent or less severe. You can still fuck up by the numbers in C#; it happens much less often, and the result is usually not so spectacular. Usually you have to mishandle authorization control, such as by creating an SQL injection allowing the remote user to obtain database privileges (the application presents certain operations to the user, and uses a database account whose set of possible operations encompasses those end-user operations; if the user can insert arbitrary SQL code, he has access to *all* operations the application can perform). Accidentally screwing up your program in such a way as to allow arbitrary flow control redirection is *really* hard in C#.
The whole thing is bullshit-on-hold. I already know the narrative; I've modeled the current government in abstract from bits and pieces I've picked up while not really paying attention.
You want to know how it plays out?
The government cracks the phone. It finds evidence of the shooting on there--possibly explicit, possibly vague. Regardless, it's evidence. They hold up this evidence and say, "If this hadn't been encrypted, we could have stopped this shooting!"
That's contingent on them actually cracking the phone, but it's the direction they're going. Notice the huge flaw in logic: They weren't in possession of the phone pre-shooting, and any software on the phone would be able to bypass the encryption. Network monitoring would have given them any unencrypted information. Encrypted messaging is a different facility, and any systems to look for certain key words would face both an incredible wall of false positives and misdirection by simple codes ("did you remember to pick up eggs?" "I'll buy them tonight around 8." Shooting is at 8pm). Doesn't matter; the narrative is swallowed by the masses, because people in groups don't think.
I doubt they'll fabricate evidence and claim they broke the encryption. They may be using this case as pressure, hoping to bring multiple such cases forward and continuously claim people are dying because of encryption. That's more conjecture; I'm pretty firm on their political play at the masses, but not on the power buildup via repeated demands for backdoor decryption capabilities through multiple tragedies. My models give me movie plots, but not firm projections; more data will elevate some of those movie plots to firm projections.
Just watch when they *do* break someone's encryption in one of these cases. Watch what they say after. They'll spin a narrative about how the encryption allowed the crime to occur, about how they could have stopped it if only there was an encryption back door.
It's the politics part that usually applies. The strlcpy() thing cited is politics, just not governmental politics.
I've had three arguments with Theo. The first was over his claim that position-independent executables were "very expensive," which I responded to by benchmarking the entire execution of a Linux OS and determining that the system would indeed slow down if it couldn't find 4 seconds of CPU idle time out of each day (the hit was 1% or 6%, depending on optimization; but the proportion of time spent in main executable code was 0.018% of all execution, since everything happens in libraries). The second was an argument over whether static checking was useful, in which Theo claimed a tool like Coverity PROTECT would *decrease* code security (OpenBSD now uses Coverity PROTECT to look for vulnerabilities). The third was a buck against his analysis of OpenSSL's Heartbleed vulnerability, which he claimed was vulnerable due to the use of an internal ring buffer allocator rather than malloc(), instead of by virtue of not performing bounds checking (there were *several* points he was wrong on).
Ulrich Drepper argued with Michael Meeks about a lot of dynamic-link-time optimizations, then huddled down for a month and released the same code with his name slapped on it. He's got a history of NIH and of stuff like you see with strlcpy().
All of these things are political battles. Theo's issue with PIE was that PaX and GRSecurity were pushing PIE, and he didn't think about that for W^X; his issue with Coverity was that he'd been loudly proclaiming OpenBSD is perfect and secure, and mocking other projects for having all these holes; and his main attack on OpenSSL was basically a large claim that we'd have seen Heartbleed coming if we used OpenBSD malloc() (again: OpenBSD will save the world!). Drepper similarly is trying to prove the universe revolves around him.
These are people who wrote operating systems, or significant parts thereof. They say and do really fucking stupid things, constantly; they've got one good trick and a huge padding of wargable. If you watch, you'll see they screw up technical concepts they should know dead cold because they're more focused on politics.
It's not really binary. Humans are complex, and that complexity gives you about a billion ways to prove you're an idiot. This works so well that you can have genius-level skill in a highly-complex discipline and still be an idiot *within* *that* *discipline*. Matthew Garrett occasionally accuses Linus Torvalds of this, and not just because he's butthurt about being associated with Microsoft Blowjobs.
This is all true; and yet the media machine dismisses all denial-of-service attacks, all bugs that just crash your application, and instead jump up and down with white sheets making spooky noises whenever they see the words "Remote Code Execution." The report here is that glibc has this huge, terrifying attack surface turning any application into a hacker back door paradise; that assessment is false.
Did you hear about CVE-2015-1473, allowing a local or remote user to trigger a denial-of-service in glibc? What about CVE-2014-6040, the iconv() denial-of-service causing a crash in glibc iconv(), which converts between encoded 8-bit text e.g. Windows smart quotes, ASCII standard, and Latin-1? Good places to throw HTTP requests that absolutely murder your Apache2 web server. CVE-2014-8121, glibc infinite loop in nsswitch facilities, lets a remote attacker make glibc perform a look-up while already performing a look-up, repeatedly resetting the file pointer forever.
Nobody really cares all that much. "Hackers can take over the entire Internet!" is a better headline.
Yes, it requires even-more-unlikely scenarios.
Among those, many of the techniques you've provided require the ability to write to arbitrary memory locations (in which case you can use *that* bug to emulate *this* bug, so no change). Some rely on Windows Safe Exception Handling exploits. One of the methods given is "attack a function that isn't protected", which is a handwave.
The phrack article has a program exploiting itself by inspecting its own memory space and then jumping over terminator canaries. That is: rather than strcpy(buffer, baddata), it strcpy(buffer+offset, baddata). In practice, this means having a way to change the strcpy() call's target--i.e. a way to write arbitrary data to arbitrary memory. The other attack overwrites the shadow pointers, which is another write-anything-anywhere style attack. Both such attacks can fully emulate *this* bug, and so would provide the same capability of exploitation of this bug. In other words: no new risk introduced by this bug.
Core's article is the same: can write to arbitrary memory locations.
Notably, the address space randomization protection would obfuscate the location of the retarray used in StackGuard, making such attacks more difficult in the same way previously stated.
In any case, all of these are ways to get around randomized canaries. They all require the ability to write to arbitrary memory, which gives you a bigger tool to perform a much broader attack. This doesn't defeat address space randomization; and address space randomization doesn't defeat having all memory be exclusively writable OR executable (meaning injecting code flat out doesn't work, even if we hand you all the keys to do so).
Think about that. In 1998, a simple overflow like this would be a quick way to exploit anything on a whim; now it just means that, if you slit the throat of a virgin goat and bathe your naked body in its blood under the light of a full moon on Winter Solstace when the planets are in alignment, you have a 1 in several billion billion chance of crashing the program due to an attempt to execute the stack, instead of crashing it due to a bounds check.
We've come a long way.
You comment about dishwashers using hot water, but not about glass that can handle sudden temperature differentials?
I'm being realistic. It's like saying you can't do any banking on the Internet because someone could steal your credit cards when you log into your bank site; that worked in 1990, but we've since started using SSL and 128-bit encryption. Banking is safe, and running around screaming that the packets go through a bunch of routers in between and someone might be able to read the data is just wargarble.
To say that this vulnerability is as big a deal as it's made out to be would require you to also acknowledge that ever logging into any banking site, ever, or using any credit card on the Internet would require immediately canceling that card and those accounts because someone has probably stolen them as soon as they went on the wire.
Anti-virus software is an arms race. This is a change to the fundamental behavior of the compiler toolchain and produced code.
Think like someone tells you dishwashers are dangerous because they use high-temperature hot water, and then your glasses all crack because they drop from 145F as they're exposed to the cold air when you open the door after a wash cycle. You then point out that your glassware is all borosilicate glass and can take a temperature drop of 120 degrees celsius across 1 second without damage. Going from boiling to ice water won't break your glass; heating it dry over an acetyloxy torch and then dumping it in an ice bath *will* shatter it.
What you're looking at here isn't a system that catches one specific attack signature. You're looking at an attack which fundamentally relies on overflowing a buffer on the stack, rewriting RETP with an address on the stack that contains code injected as part of the overflow, and then jumping into that code on RETL instruction. This executes your code from the stack.
Meanwhile, the software being attacked stores a runtime-randomized word between the stack variables and RETP, then verifies it hasn't changed before a call to RETL, so you have to guess a 32-bit or 64-bit integer (1 in 4 billion or 1 in 16 billion*billion). If that fails, the system *still* has randomized the stack base, so you have to load a value into RETP which points to your code on the stack, which can be in any of thousands or millions of locations. Should you manage to guess both a one-in-four-billion and a one-in-524-thousand value simultaneously (one-in-2251-billion-billion) (or bigger on 64-bit), the stack is still non-executable: the OS will claim a general protection fault due to trying to execute non-executable memory.
That means this attack can't be carried out successfully without extreme luck (1 in 9.7 billion billion billion) or advanced knowledge of the program's address space (which the attacker must inspect while the program is running--it changes on every run); and even then, the attack has to do something distinctly other than injecting code. Heap, main executable, and library load addresses are also randomized on each run, so luck in dodging out the primary protections leads directly to rolling bigger dice in hopes of getting lucky a third time.
In this particular attack, you can't just launch an attack at a target. You have to gain control of DNS responses for that target, then wait for the target to make a DNS query. All of the above then apply. Good luck.
Ulrich Drepper is an idiot. So is Theo da Rat. They're like rednecks who can fix absolutely any automobile you bring them, but are too stupid to think beyond the end of a wrench; these rednecks just know how to write C.
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.
Ok first when you use quote marks it means you are quoting. This is not a quote so is false.
Right, because it's not like quotation marks are routinely used that way in millions of books, papers, news articles, and other English language materials. Look, kid, maybe when you start reading, you'll learn about indirect quotation and its use in modern English.
No one claimed this was a solution for all of Europe, yet this was your argument.
Well at the scale given, it's not useful for exporting power to Europe--which seems to be the plan. Any significant supply of European power is going to need a large land area.
You argued that the land could be better for habitation and food production,
No, I didn't. We've covered this, Timmy. I issued comparisons for scale and also described the scale of land usage when trying to provide power via solar. For a block of land including living space and solar power generation, 72% of the land goes to solar power and 28% is living space. See the below:
to go all-solar at this efficiency, 72% of the land must be solar, assuming densely-packed apartments filled with families (New York apartment projects).
I also said this:
That space of land could feed over 6,000 people [farmlandlp.com] if properly arable
You see, 6,000 acres of land is... what? It's uh. Some feet. And square feet. ... how big is that in bananas? What *is* 6,000 acres of land? Is it bigger than a square cubit?
Answer: 6,000 acres of land is the same size as an area of arable farm land which feeds 6,000 people for one year.
Let's examine another quote, one that will benefit you greatly since you dropped out of school before second grade:
An analogy is a comparison in which an idea or a thing is compared to another thing that is quite different from it. It aims at explaining that idea or thing by comparing it to something that is familiar.
So to answer your question:
You made the claim that solar would use up our food producing land (see the quotes of your own words above), and this was the claim that was argued against (ie it's not using food producing land, as shown in the TFA). Do you understand now?
No, I didn't make the claim that solar would use up our food producing land. I made analogies, and drew scale between living space and the solar power production space needed to produce electricity for that space. By the way, THREE FUCKING TIMES AS MUCH LAND AREA devoted to solar to supply power. For the land needed to house 400 people, you need to install solar panels across the land needed to house 1,200 people in order to give them solar-based electricity. That's also analogical; remember that *analogies* are inherently *comparisons*, so you should be able to do this magical thing that intelligent people do called *visualization* and get a direct grasp of scale of solar installation.
Or you could continue being a deceptive worm and try to get people to juggle numbers without reference in their heads, hoping they don't understand what those numbers mean in real-world terms.