A primary stock market isn't a necessity for investment. Warren Buffet walked directly into Bank of America and gave them $2 billion in investment capital. Stock market IPOs only fund established corporations who are ready to go public on the exchanges and meet the rigorous requirements of "Being worth a lot of money" to get on the NYSE. Otherwise you get penny stocks who can capitalize a few thousands by selling 1000 shares for 20 bucks.
Theo seems to me to be loudly proclaiming that the bug couldn't have existed with a certain feature, which I think is technically incorrect. I'm mostly in (1) camp, I just think Theo's statements are directly contradictory to this sentiment.
Better practices would not have prevented this bug; they would have reduced the probability of such a bug. Several people didn't realize there was no validation there, but specific test cases and fuzzing/analysis or even just the culture of better programming standards may have changed that. Or not. These things do, however, reduce defect rate--they don't give you zero defects--and so the likelihood of this bug, like any other, would be lower; we'd screen out X% of total defects, essentially, and hopefully this would be one of those.
Frama-C found Heartbleed, but Coverity didn't. Frama-C is GPL, and you can annotate your program to help with analysis. As far as I understand, Frama-C found that the data that was used for memcpy()'s size came from a mystical function that originates data from some untraceable source, was an unsigned int (0..65535 value), and was never validated against the size of the source array, which had the possibility to be smaller than 65535. Because the length of copied data could be up to 65535 bytes and the length of the source data could be smaller than 65535 bytes and the length of the copy was not computed based on the length of the source in such a way as to bound the length to the length of the source, it was conceivably possible to copy more data than was actually there. Hence Frama-C decided this code was, somehow, broken.
I used to be a huge fan of static checking. Looking at Frama-C's plug-ins, I'm wishing there were things like this for Python. It even has impact analysis (when you change something, what parts of the code may be affected? What are you really changing?).
You're taking an overly pessimistic view with "doesn't help".
First off, with good judges, this provides stronger guidelines. It also makes it easier for the American People to understand what a law will and will not do. The method may be complex and wordy and a nightmarish hell of legalese, but the mission is clear in its goal and its bounds.
Second, bad judges can only distort reality so far. They categorically cannot simply make up law as they go; they need a hook, something that can withstand some legal scrutiny. The more legal scrutiny they can withstand, the harder it is for another judge to evaluate the appeal and overturn the decision. Further, judges who blatantly act in violation of the law--for example, judges who are NAMBLA members and give everyone with loads of child pornography and a dozen fourth-grade fuckbuddies a NOT GUILTY verdict (which you cannot overturn in appeal!)--can be impeached! That's right: if you bang a fifth grader, bring in a video, and the judge says, "This shouldn't be fucking illegal, I like screwing kids! NOT GUILTY, CASE DISMISSED!", he can be brought up on charges and stripped of his appointment!
I am pushing judicial decisions closer to this eventuality, where you must come up with some hella cool wizard shit to twist your way around the law, and it's going to be blunt and obvious and impossible to stand up to scrutiny in more cases than current, and in many cases doing so will get you brought up on charges. Further, congress should be less inclined to try to get shit through, as it will look bad for them and there will be valid complaint that this shit doesn't fit with the mission of the law, and then we have to rewrite the mission in three languages, every provision of the law has to abide by all three versions 100%, so we should just write another bill.
The higher capital gains on the traded stock, the lower the return will be, so the stock price will be lower, so my returns will be lower as I sell my founding shares. Result? Less investment in start-ups.
There is a huge body of evidence that supports this – the higher the capital gains the lower the investment in the economy.
Investment in stock doesn't invest in the economy.
Remember when SIRI (Sirius Satellite Radio) was hot? All those investors buying, trading? Yeah, they weren't giving money to Sirius Satellite Radio Corporation. They were giving it to other people. Mostly, when it peaked, they were selling off to day traders and funds which must carry a certain amount of technology stock, and then when it settled and started to climb from the bottom they were buying back in and giving less money to those people, pumping money from stupid people to their smart investment banker people.
Why would I invest in startup under your proposal?
Because my proposal increases taxes on the exchanges where you pass money back and forth between you and idiots, but doesn't increase (or decreases) taxes when you go to a business and go, "I would like to buy into your business because I feel it is going somewhere. Here is millions of dollars for you to spend pursuing your business goals."
In short: investors at the NYSE aren't putting money in the pockets of the businesses whose stocks they're buying. The Harvard Faculty Petition to divest in fossil fuel energy companies isn't pulling Harvard's money away from Exxon; it's just selling pink sheets of XOM to other people who aren't necessarily related to XOM (it could, actually, create a stock price drop which Exxon-Mobil may respond to by issuing a stock buy-back, becoming more vested in themselves, so that the huge stock sell-off actually allows them to get even more money by issuing more stock into the market later; but that's a voluntary move by Exxon-Mobil, and they don't need to buy or sell or issue any stock in response to Harvard selling $500 million XOM).
Rigorous practices and robust design concepts universally reduce the likelihood of bad things. Trust me, I'm a risk management guy, I know how this shit works.
So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.
The above quote by Theo spawned a whole lot of chatter about how Heartbleed was caused by double-free or use-after-free. The above says that memory would be handed to munmap(), which people have interpreted as to say, "Oh, OpenSSL was copying a buffer that it had already freed, that's heartbleed". No, not really. There are all kinds of tangential arguments here--for example: if it worked as above, the allocator could have also put an unmapped block between allocations, making whether or not another allocation was freed irrelevant. But really, the bug is this: a memcpy() from a validly-allocated buffer that hasn't been freed, but it copies a lot more than the buffer (hence the prior statement: if your allocator catches this, it's of a design where use-after-free doesn't matter in this context, or your design is lacking).
Coverity reported 173 additional "use after free" bugs.
None of which caused heartbleed. Heartbleed gets a TLS heartbeat request that says "65000 HELLO", allocates 65,000 bytes, goes to the "H" in "HELLO" and copies 65,000 bytes into the new buffer. The problem is the correctly-allocated source buffer isn't that long, and it reads off the end. This isn't a "use after free" bug; a "use after free" bug is when you free(p) and then dereference (p) without first assigning it the value of a valid area of allocated memory. Reading off the end of a buffer--whether you read into freed, allocated, or whatever memory--is not use-after-free, but rather a wholly other class of bugs that could happen to read released memory as a side effect in some conditions, primarily because it executes a read overflow which has undefined behavior which could do ANYTHING.
In technical terms, the memory being read by heartbleed is never read after free(); rather it's invalid, because the memory address is reached without the use of any information that would indicate if there is anything at that address (mapped, unmapped, allocated, unallocated). From the point of the C standard and any sane way of evaluating this behavior, that memory doesn't exist, trying to read that memory is bad, you're bad for trying to read that memory, and whatever happens after this is nobody's fault but your own and could be nothing of import or the summoning of Cthulu.
Don't you suppose that in the process of fixing such bugs, it is likely that correctness issues like this one would have been caught?
I actually do suppose that it's more likely; however, to say that these technical factors are to blame for Heartbleed is wholly wrong. Heartbleed is its own bug, not a memory allocator bug or a double-free bug or a use-after-free bug. Heartbleed would have been found if more rigorous testing were employed IF AND ONLY IF said testing included the validation of this user-supplied input, in which case someone would have said, "We should test if we can send it a payload length that's bigger than the actual payload," and someone else would have said, "Uh... the... code just reads the payload length. We should test that in like, ten minutes, after I fix this." All non-human technical factors are a farce in this particular theater.
For what it's worth, multiple people actually did review this body of code, looked directly at these lines, evaluated them, and saw that it was good. THEY WERE WRONG.
The Frama-C value analyzer tracks an integer variable using an interval: a representation of the smallest and largest value that the integer could contain at some program point. Upon reaching the problematic memcpy() call in t1_lib.c, the value of payload is in the interval [0..65535]. This interval comes from the n2s() macro which turns two arbitrary-valued bytes from the client into an unsigned int
The dest argument of this memcpy() turns out to be large enough. However, the source buffer is way too small. Frama-C would gripe about this and it would not shut up until the bug was really fixed.
How much effort would be required to push OpenSSL through Frama-C? I don’t know, but wouldn’t plan on getting this done in a week or three.
I'm saying it's semantically identical, not that it would happen. The question is WHICH OPTIONS SHOULD BE SUPPLIED? What if your desired option isn't one of them? And in all cases, all other options are extraneous to you and just clutter. These are good arguments for the way things were done.
Still not equivalent. The law can try to call one thing another thing, and indeed can do so in its own context; but if law A says that a "tax" is one thing, and law B says "this is not a tax, it's a charge we implemented by which you give money to the IRS", then law B is trying to bullshit you out of being a tax.
Now granted you can argue Roberts' legal theory--although I encourage you to get better arguments, as you just argued that if the Senate writes a tax law it's valid because "it's not a tax law because it came from the Senate" and thus you can't reject it on the grounds that "the House must originate tax laws" because it was originated from the Senate and thus isn't really a tax law--but he is interpreting events and actions and definitions and legal things as they pertain to law.
The same thing would, of course, happen to the ACA in my system. It would say at the top: "...without implementing new taxes." Then we would argue over whether a "penalty collected by the IRS" is a tax disguised by semantic bullshit. Now of course there are arguments on both sides: it's a tax collected by the IRS. On the other hand, it's only collected by the IRS under certain conditions, therefor it's a fine (penalty). Or is a conditional penalty which is not applied to poor people actually structured as a progressive tax, and thus it is a tax? (That one's actually pretty harsh: your income is below a certain threshold, you're not eligible to be penalized--that sounds less like a fine and more like a progressive tax system.)
These arguments are fine. It's hard, however, to come back and say, "We also added provisions to earmark 750 million dollars for highway spending." That's out of scope: the bill's mission doesn't talk about infrastructure projects.
Well think about it. A company gets money when they IPO, but that only happens when established. Beyond that, every stock trade just moves money from one investor to another; the company is not attached to common stock.
On the other hand, venture capital--equity investment into a business such that you own part of the business, up to and including direct stock transactions and holding in the business (preferred stock, shareholders)--directly funds the business. You don't buy pink sheets on the exchange; you go to the business, give the business money, and get holding in the business.
Why should we consider these things the same? Putting money into a business gives it capitalization. Buying a bond off another investor, or buying a stock off another investor, doesn't do this.
Likewise securities and commodities trading are different. Commodities training can push the spot price of commodities up, or stabilize it so it doesn't climb too high. Securities trading doesn't trade physical things and doesn't impact the physical world--you don't get 15 bushels of Microsoft stock showing up on a boat to be peeled and sold to restaurants.
Yes but then somebody would have to guess which options to supply in the checkbox, and could get it wrong or add pointless options. This is the same as adding an "extensions light" site that only supplies extensions blessed by the GNOME devs as "the extensions you should use, if any".
Yeah. I don't agree with the conjectures about how fixing X problem would have caught this because it would have to be tested/exploited to be caught even in the absolute most strict case (100% of all code except that one function correct). If somebody would have thought to do a test for a bad payload length, they would have thought to fix it.. or got a huge packet back and gone wtf? And if you tested it otherwise, you wouldn't trigger any invalid behavior.
A static checker did specifically identify heartbleed. Nobody really ran a static checker either.
I don't think there's something broken about OpenBSD's allocator. Performance trade-off, yeah. Broken, no.
I think the target of all this ire is a lot of technically incorrect bullshit, like calling freelists irresponsible programming or claiming that something in the allocator broke OpenSSL (it didn't; the bug was wholly self-contained), or trying to claim that OpenBSD would have caught the bug for some odd reason or another when it can only be caught in that way (with secure allocators) when actively exploited--and most targets are not OpenBSD and do not use an OpenBSD-style allocator.
Theo is making up theoretical situations and giving blatantly incorrect technical analysis of things that, while broken, are either not broken in that way or would not have mitigated that bug if fixed, either in theory or in practice.
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.
We should probably raise capital gains tax on unbacked securities (i.e. the stock market). It's just a money transfer vehicle. Investment in start-ups and other venture behavior is useful, but buying from the fucking exchange doesn't do shit.
Yes yes of course but you're missing the point. We'll ignore that sarcasm doesn't carry and that the exploit mitigation stuff in OpenSSL has been repeated again and again without a hint of irony and so one may be lead to believe such a thing exists in OpenSSL.
First off,
And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.
Here's the thing: OpenBSD is a hobby OS. It's like Linux with grsecurity: yes they've mitigated all this shit ages ago, yes people run grsecurity in production, yes anything that grsecurity "would have prevented" is effectively unprotected because damn near no one runs grsecurity. If someone asked me to bet on whether there was more OpenBSD or more grsecurity in production on machines installed by system administrators starting from bare metal (i.e. not appliances that are mystery boxes that nobody reads the logs on nor updates nor understands anyway), I would avoid the bet.
OpenBSD's allocator is what we call "Proof of Concept". OpenBSD is what we call "Proof of Concept". It exists somewhere in real life, you can leverage it (I've leveraged proof-of-concept exploit code from Bugtraq in actual exploit kits), but it's not this ubiquitous thing that's out there enough to have an impact on the real world. BSDs are estimated to be about 1.0% of all servers on the Internet (as of February 2014, sorry don't have current numbers), OpenBSD a portion of that, FreeBSD a bigger portion. That means most of everyone interesting--Suntrust, Bank of America, slashdot, the NSA, Verisign, Microsoft, Google--is running a non-OpenBSD operating system with no such protections.
And again, the concept of allocation caching is common. Freelists are used when allocations are all the same size; that gripe is essentially that a valid data object is not valid because they dislike it. Plenty of software uses freelists, and freelists are a generalization of the object pool software design pattern used for database connection caching in ORMs, token caching in security systems, and network buffers (ring buffer...). I would be surprised if OpenBSD's libc and kernel didn't make use of freelists or object pools somewhere.
Also it's funny that you ignored the whole "this vulnerability would have happened basically everywhere anyway and the impact would have been the same even if all other code besides what's in this one function was perfect" thing. Mickens warned me about people like you:
Security people are like smarmy teenagers who listen to goth music: they are full of morbid and detailed monologues about the pervasive catastrophes that surround us, but they are much less interested in the practical topic of what people should do before we’re inevitably killed by ravens or a shortage of black mascara.
The “threat model” section of a security paper resembles the script for a telenovela that was written by a paranoid schizophrenic: there are elaborate narratives and grand conspiracy theories, and there are heroes and villains with fantastic (yet oddly constrained) powers that necessitate a grinding battle of emotional and technical attrition. In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary is
the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://./ If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that
Extensions are preferable to checkboxes because you may have 8000 preferences on how something should be done, and then decide to implement three of them, two of which damn near nobody really cares about. So you get a cluttered configuration system with all these preference checkboxes, most of which goes unused and is in the way.
Extensions let people slap in their own preferences, make subtle design decisions, and not clutter the interface with 800 ways that alt-tab should behave.
Actually, a certain amount of effort is required to understand code. Depending on how the language provides its interfaces, the abstract and logical ways in which people think and which programmatic processes normally flow based on how people envision them are either simple to interpret (for humans) or immensely complex to interpret.
Because of this, one language may have an advantage over another in terms of both speed of program implementation and frequency of defects. Fewer objects for programmers to track, and more objects are more naturally understood, thus less mental effort required to ensure correct code, and fewer cases where multiple visual validations by different people will produce the same corner case where incorrect code is incorrectly interpreted as correct.
The freelist is not an "exploit mitigation countermeasure", but rather standard allocation caching behavior that many high-rate allocation applications and algorithms implement--for example, ring buffers are common as all hell. The comment even says that it's done because performance on allocators is slow.
Further, the only bug in Heartbleed was a READ OVERFLOW BUG caused by lack of input validation. It would actually read that a user said "This heartbeat is 65 thousand bytes long", allocate 65 thousand bytes plus room for instrumentation data, put instrumentation data in place, and then copy 65 thousand bytes from a request that was 1 byte long. While there are mitigation techniques, most allocators--anything that uses brk() to allocate the heap for allocations smaller than say 128KB (glibc's pmalloc and freebsd's kmalloc both use brk() until you ask for something bigger than 128KB, then use mmap())--don't do that. That's how this flaw worked: It would just read 64KB, most likely from the brk() area, and send it back to you.
Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD. Write overflows would kill canaries, but they actually allocated enough space to copy the too-large read into. And the code is, of course, correct for invalid input.
Theo made a lot of noise about how all these other broken things were responsible for heartbleed, when the reality is one failed validation carries 100% of the weight for Heartbleed. If you perfectly cleaned up OpenSSL except for that single bug, slapped it on Linux with the default allocator, and ran it, it would still have the vulnerability. And it only behaves strange when being exploited--and any test would have sent back a big packet, raising questions.
There was never really any hope that this was going to be caught before it was in the wild and "possibly had leaked your SSL keys'. It may have happened sooner, maybe, maybe not; but it still would have been a post-apocalyptic shit storm. And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.
But the bar is set higher, and legally there is a binding here. It now becomes extremely difficult to justify your stance.
Judges continuously rule that a law cannot take an action: marriage laws cannot take an action to exclude, abortion laws cannot take an action to rule abortions improper medical practice, etc. While you can swing these both ways, it is difficult to say "This law makes efforts in social policy by the criminalization of specific behaviors related to sexual activity with minors..." and say, "Well, the line 'Raise 15% tax against imports of fine tobacco from India', falls within the scope of Congress' power". The law's mission doesn't say anything about a tax, just about making sexual activity with minors criminal offenses. A judge would literally have to abandon all pretense of interpreting rights and other complex laws and simply state, "BECAUSE I SAY SO!"
But they also gave money to Comcast, which means that maybe Verizon or AT&T can hit them up and get money.
If they dodged Comcast in that way, then all Verizon or AT&T could do is expend their money to get Netflix to expend money as well, which is not as attractive.
Slashdot Mirror
A primary stock market isn't a necessity for investment. Warren Buffet walked directly into Bank of America and gave them $2 billion in investment capital. Stock market IPOs only fund established corporations who are ready to go public on the exchanges and meet the rigorous requirements of "Being worth a lot of money" to get on the NYSE. Otherwise you get penny stocks who can capitalize a few thousands by selling 1000 shares for 20 bucks.
Theo seems to me to be loudly proclaiming that the bug couldn't have existed with a certain feature, which I think is technically incorrect. I'm mostly in (1) camp, I just think Theo's statements are directly contradictory to this sentiment.
Better practices would not have prevented this bug; they would have reduced the probability of such a bug. Several people didn't realize there was no validation there, but specific test cases and fuzzing/analysis or even just the culture of better programming standards may have changed that. Or not. These things do, however, reduce defect rate--they don't give you zero defects--and so the likelihood of this bug, like any other, would be lower; we'd screen out X% of total defects, essentially, and hopefully this would be one of those.
Frama-C found Heartbleed, but Coverity didn't. Frama-C is GPL, and you can annotate your program to help with analysis. As far as I understand, Frama-C found that the data that was used for memcpy()'s size came from a mystical function that originates data from some untraceable source, was an unsigned int (0..65535 value), and was never validated against the size of the source array, which had the possibility to be smaller than 65535. Because the length of copied data could be up to 65535 bytes and the length of the source data could be smaller than 65535 bytes and the length of the copy was not computed based on the length of the source in such a way as to bound the length to the length of the source, it was conceivably possible to copy more data than was actually there. Hence Frama-C decided this code was, somehow, broken.
I used to be a huge fan of static checking. Looking at Frama-C's plug-ins, I'm wishing there were things like this for Python. It even has impact analysis (when you change something, what parts of the code may be affected? What are you really changing?).
You're taking an overly pessimistic view with "doesn't help".
First off, with good judges, this provides stronger guidelines. It also makes it easier for the American People to understand what a law will and will not do. The method may be complex and wordy and a nightmarish hell of legalese, but the mission is clear in its goal and its bounds.
Second, bad judges can only distort reality so far. They categorically cannot simply make up law as they go; they need a hook, something that can withstand some legal scrutiny. The more legal scrutiny they can withstand, the harder it is for another judge to evaluate the appeal and overturn the decision. Further, judges who blatantly act in violation of the law--for example, judges who are NAMBLA members and give everyone with loads of child pornography and a dozen fourth-grade fuckbuddies a NOT GUILTY verdict (which you cannot overturn in appeal!)--can be impeached! That's right: if you bang a fifth grader, bring in a video, and the judge says, "This shouldn't be fucking illegal, I like screwing kids! NOT GUILTY, CASE DISMISSED!", he can be brought up on charges and stripped of his appointment!
I am pushing judicial decisions closer to this eventuality, where you must come up with some hella cool wizard shit to twist your way around the law, and it's going to be blunt and obvious and impossible to stand up to scrutiny in more cases than current, and in many cases doing so will get you brought up on charges. Further, congress should be less inclined to try to get shit through, as it will look bad for them and there will be valid complaint that this shit doesn't fit with the mission of the law, and then we have to rewrite the mission in three languages, every provision of the law has to abide by all three versions 100%, so we should just write another bill.
Well it's too slow. Sonic is faster.
Let me detangle some stuff.
The higher capital gains on the traded stock, the lower the return will be, so the stock price will be lower, so my returns will be lower as I sell my founding shares. Result? Less investment in start-ups.
There is a huge body of evidence that supports this – the higher the capital gains the lower the investment in the economy.
Investment in stock doesn't invest in the economy.
Remember when SIRI (Sirius Satellite Radio) was hot? All those investors buying, trading? Yeah, they weren't giving money to Sirius Satellite Radio Corporation. They were giving it to other people. Mostly, when it peaked, they were selling off to day traders and funds which must carry a certain amount of technology stock, and then when it settled and started to climb from the bottom they were buying back in and giving less money to those people, pumping money from stupid people to their smart investment banker people.
Why would I invest in startup under your proposal?
Because my proposal increases taxes on the exchanges where you pass money back and forth between you and idiots, but doesn't increase (or decreases) taxes when you go to a business and go, "I would like to buy into your business because I feel it is going somewhere. Here is millions of dollars for you to spend pursuing your business goals."
In short: investors at the NYSE aren't putting money in the pockets of the businesses whose stocks they're buying. The Harvard Faculty Petition to divest in fossil fuel energy companies isn't pulling Harvard's money away from Exxon; it's just selling pink sheets of XOM to other people who aren't necessarily related to XOM (it could, actually, create a stock price drop which Exxon-Mobil may respond to by issuing a stock buy-back, becoming more vested in themselves, so that the huge stock sell-off actually allows them to get even more money by issuing more stock into the market later; but that's a voluntary move by Exxon-Mobil, and they don't need to buy or sell or issue any stock in response to Harvard selling $500 million XOM).
Learn how the market works.
Rigorous practices and robust design concepts universally reduce the likelihood of bad things. Trust me, I'm a risk management guy, I know how this shit works.
So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.
The above quote by Theo spawned a whole lot of chatter about how Heartbleed was caused by double-free or use-after-free. The above says that memory would be handed to munmap(), which people have interpreted as to say, "Oh, OpenSSL was copying a buffer that it had already freed, that's heartbleed". No, not really. There are all kinds of tangential arguments here--for example: if it worked as above, the allocator could have also put an unmapped block between allocations, making whether or not another allocation was freed irrelevant. But really, the bug is this: a memcpy() from a validly-allocated buffer that hasn't been freed, but it copies a lot more than the buffer (hence the prior statement: if your allocator catches this, it's of a design where use-after-free doesn't matter in this context, or your design is lacking).
Coverity reported 173 additional "use after free" bugs.
None of which caused heartbleed. Heartbleed gets a TLS heartbeat request that says "65000 HELLO", allocates 65,000 bytes, goes to the "H" in "HELLO" and copies 65,000 bytes into the new buffer. The problem is the correctly-allocated source buffer isn't that long, and it reads off the end. This isn't a "use after free" bug; a "use after free" bug is when you free(p) and then dereference (p) without first assigning it the value of a valid area of allocated memory. Reading off the end of a buffer--whether you read into freed, allocated, or whatever memory--is not use-after-free, but rather a wholly other class of bugs that could happen to read released memory as a side effect in some conditions, primarily because it executes a read overflow which has undefined behavior which could do ANYTHING.
In technical terms, the memory being read by heartbleed is never read after free(); rather it's invalid, because the memory address is reached without the use of any information that would indicate if there is anything at that address (mapped, unmapped, allocated, unallocated). From the point of the C standard and any sane way of evaluating this behavior, that memory doesn't exist, trying to read that memory is bad, you're bad for trying to read that memory, and whatever happens after this is nobody's fault but your own and could be nothing of import or the summoning of Cthulu.
Don't you suppose that in the process of fixing such bugs, it is likely that correctness issues like this one would have been caught?
I actually do suppose that it's more likely; however, to say that these technical factors are to blame for Heartbleed is wholly wrong. Heartbleed is its own bug, not a memory allocator bug or a double-free bug or a use-after-free bug. Heartbleed would have been found if more rigorous testing were employed IF AND ONLY IF said testing included the validation of this user-supplied input, in which case someone would have said, "We should test if we can send it a payload length that's bigger than the actual payload," and someone else would have said, "Uh... the... code just reads the payload length. We should test that in like, ten minutes, after I fix this." All non-human technical factors are a farce in this particular theater.
For what it's worth, multiple people actually did review this body of code, looked directly at these lines, evaluated them, and saw that it was good. THEY WERE WRONG.
The Frama-C value analyzer tracks an integer variable using an interval: a representation of the smallest and largest value that the integer could contain at some program point. Upon reaching the problematic memcpy() call in t1_lib.c, the value of payload is in the interval [0..65535]. This interval comes from the n2s() macro which turns two arbitrary-valued bytes from the client into an unsigned int
The dest argument of this memcpy() turns out to be large enough. However, the source buffer is way too small. Frama-C would gripe about this and it would not shut up until the bug was really fixed.
How much effort would be required to push OpenSSL through Frama-C? I don’t know, but wouldn’t plan on getting this done in a week or three.
Thank you for playing.
I'm saying it's semantically identical, not that it would happen. The question is WHICH OPTIONS SHOULD BE SUPPLIED? What if your desired option isn't one of them? And in all cases, all other options are extraneous to you and just clutter. These are good arguments for the way things were done.
Still not equivalent. The law can try to call one thing another thing, and indeed can do so in its own context; but if law A says that a "tax" is one thing, and law B says "this is not a tax, it's a charge we implemented by which you give money to the IRS", then law B is trying to bullshit you out of being a tax.
Now granted you can argue Roberts' legal theory--although I encourage you to get better arguments, as you just argued that if the Senate writes a tax law it's valid because "it's not a tax law because it came from the Senate" and thus you can't reject it on the grounds that "the House must originate tax laws" because it was originated from the Senate and thus isn't really a tax law--but he is interpreting events and actions and definitions and legal things as they pertain to law.
The same thing would, of course, happen to the ACA in my system. It would say at the top: "...without implementing new taxes." Then we would argue over whether a "penalty collected by the IRS" is a tax disguised by semantic bullshit. Now of course there are arguments on both sides: it's a tax collected by the IRS. On the other hand, it's only collected by the IRS under certain conditions, therefor it's a fine (penalty). Or is a conditional penalty which is not applied to poor people actually structured as a progressive tax, and thus it is a tax? (That one's actually pretty harsh: your income is below a certain threshold, you're not eligible to be penalized--that sounds less like a fine and more like a progressive tax system.)
These arguments are fine. It's hard, however, to come back and say, "We also added provisions to earmark 750 million dollars for highway spending." That's out of scope: the bill's mission doesn't talk about infrastructure projects.
Well think about it. A company gets money when they IPO, but that only happens when established. Beyond that, every stock trade just moves money from one investor to another; the company is not attached to common stock.
On the other hand, venture capital--equity investment into a business such that you own part of the business, up to and including direct stock transactions and holding in the business (preferred stock, shareholders)--directly funds the business. You don't buy pink sheets on the exchange; you go to the business, give the business money, and get holding in the business.
Why should we consider these things the same? Putting money into a business gives it capitalization. Buying a bond off another investor, or buying a stock off another investor, doesn't do this.
Likewise securities and commodities trading are different. Commodities training can push the spot price of commodities up, or stabilize it so it doesn't climb too high. Securities trading doesn't trade physical things and doesn't impact the physical world--you don't get 15 bushels of Microsoft stock showing up on a boat to be peeled and sold to restaurants.
No, I mean go to another provider who is on Comcast's network, pay them to colo for bandwidth, so that Comcast isn't doing business with them.
Yes but then somebody would have to guess which options to supply in the checkbox, and could get it wrong or add pointless options. This is the same as adding an "extensions light" site that only supplies extensions blessed by the GNOME devs as "the extensions you should use, if any".
Yeah. I don't agree with the conjectures about how fixing X problem would have caught this because it would have to be tested/exploited to be caught even in the absolute most strict case (100% of all code except that one function correct). If somebody would have thought to do a test for a bad payload length, they would have thought to fix it.. or got a huge packet back and gone wtf? And if you tested it otherwise, you wouldn't trigger any invalid behavior.
A static checker did specifically identify heartbleed. Nobody really ran a static checker either.
I don't think there's something broken about OpenBSD's allocator. Performance trade-off, yeah. Broken, no.
I think the target of all this ire is a lot of technically incorrect bullshit, like calling freelists irresponsible programming or claiming that something in the allocator broke OpenSSL (it didn't; the bug was wholly self-contained), or trying to claim that OpenBSD would have caught the bug for some odd reason or another when it can only be caught in that way (with secure allocators) when actively exploited--and most targets are not OpenBSD and do not use an OpenBSD-style allocator.
Theo is making up theoretical situations and giving blatantly incorrect technical analysis of things that, while broken, are either not broken in that way or would not have mitigated that bug if fixed, either in theory or in practice.
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.
We should probably raise capital gains tax on unbacked securities (i.e. the stock market). It's just a money transfer vehicle. Investment in start-ups and other venture behavior is useful, but buying from the fucking exchange doesn't do shit.
Yes yes of course but you're missing the point. We'll ignore that sarcasm doesn't carry and that the exploit mitigation stuff in OpenSSL has been repeated again and again without a hint of irony and so one may be lead to believe such a thing exists in OpenSSL.
First off,
And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.
Here's the thing: OpenBSD is a hobby OS. It's like Linux with grsecurity: yes they've mitigated all this shit ages ago, yes people run grsecurity in production, yes anything that grsecurity "would have prevented" is effectively unprotected because damn near no one runs grsecurity. If someone asked me to bet on whether there was more OpenBSD or more grsecurity in production on machines installed by system administrators starting from bare metal (i.e. not appliances that are mystery boxes that nobody reads the logs on nor updates nor understands anyway), I would avoid the bet.
OpenBSD's allocator is what we call "Proof of Concept". OpenBSD is what we call "Proof of Concept". It exists somewhere in real life, you can leverage it (I've leveraged proof-of-concept exploit code from Bugtraq in actual exploit kits), but it's not this ubiquitous thing that's out there enough to have an impact on the real world. BSDs are estimated to be about 1.0% of all servers on the Internet (as of February 2014, sorry don't have current numbers), OpenBSD a portion of that, FreeBSD a bigger portion. That means most of everyone interesting--Suntrust, Bank of America, slashdot, the NSA, Verisign, Microsoft, Google--is running a non-OpenBSD operating system with no such protections.
And again, the concept of allocation caching is common. Freelists are used when allocations are all the same size; that gripe is essentially that a valid data object is not valid because they dislike it. Plenty of software uses freelists, and freelists are a generalization of the object pool software design pattern used for database connection caching in ORMs, token caching in security systems, and network buffers (ring buffer...). I would be surprised if OpenBSD's libc and kernel didn't make use of freelists or object pools somewhere.
Also it's funny that you ignored the whole "this vulnerability would have happened basically everywhere anyway and the impact would have been the same even if all other code besides what's in this one function was perfect" thing. Mickens warned me about people like you:
Security people are like smarmy teenagers who listen to goth music: they are full of morbid and detailed monologues about the pervasive catastrophes that surround us, but they are much less interested in the practical topic of what people should do before we’re inevitably killed by ravens or a shortage of black mascara.
The “threat model” section of a security paper resembles the script for a telenovela that was written by a paranoid schizophrenic: there are elaborate narratives and grand conspiracy theories, and there are heroes and villains with fantastic (yet oddly constrained) powers that necessitate a grinding battle of emotional and technical attrition. In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://./ If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that
Extensions are preferable to checkboxes because you may have 8000 preferences on how something should be done, and then decide to implement three of them, two of which damn near nobody really cares about. So you get a cluttered configuration system with all these preference checkboxes, most of which goes unused and is in the way.
Extensions let people slap in their own preferences, make subtle design decisions, and not clutter the interface with 800 ways that alt-tab should behave.
Actually, a certain amount of effort is required to understand code. Depending on how the language provides its interfaces, the abstract and logical ways in which people think and which programmatic processes normally flow based on how people envision them are either simple to interpret (for humans) or immensely complex to interpret.
Because of this, one language may have an advantage over another in terms of both speed of program implementation and frequency of defects. Fewer objects for programmers to track, and more objects are more naturally understood, thus less mental effort required to ensure correct code, and fewer cases where multiple visual validations by different people will produce the same corner case where incorrect code is incorrectly interpreted as correct.
He is technically incapable of evaluating what's actually happening, and likes to go off-list when he's angry and wrong.
The freelist is not an "exploit mitigation countermeasure", but rather standard allocation caching behavior that many high-rate allocation applications and algorithms implement--for example, ring buffers are common as all hell. The comment even says that it's done because performance on allocators is slow.
Further, the only bug in Heartbleed was a READ OVERFLOW BUG caused by lack of input validation. It would actually read that a user said "This heartbeat is 65 thousand bytes long", allocate 65 thousand bytes plus room for instrumentation data, put instrumentation data in place, and then copy 65 thousand bytes from a request that was 1 byte long. While there are mitigation techniques, most allocators--anything that uses brk() to allocate the heap for allocations smaller than say 128KB (glibc's pmalloc and freebsd's kmalloc both use brk() until you ask for something bigger than 128KB, then use mmap())--don't do that. That's how this flaw worked: It would just read 64KB, most likely from the brk() area, and send it back to you.
Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD. Write overflows would kill canaries, but they actually allocated enough space to copy the too-large read into. And the code is, of course, correct for invalid input.
Theo made a lot of noise about how all these other broken things were responsible for heartbleed, when the reality is one failed validation carries 100% of the weight for Heartbleed. If you perfectly cleaned up OpenSSL except for that single bug, slapped it on Linux with the default allocator, and ran it, it would still have the vulnerability. And it only behaves strange when being exploited--and any test would have sent back a big packet, raising questions.
There was never really any hope that this was going to be caught before it was in the wild and "possibly had leaked your SSL keys'. It may have happened sooner, maybe, maybe not; but it still would have been a post-apocalyptic shit storm. And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.
But the bar is set higher, and legally there is a binding here. It now becomes extremely difficult to justify your stance.
Judges continuously rule that a law cannot take an action: marriage laws cannot take an action to exclude, abortion laws cannot take an action to rule abortions improper medical practice, etc. While you can swing these both ways, it is difficult to say "This law makes efforts in social policy by the criminalization of specific behaviors related to sexual activity with minors..." and say, "Well, the line 'Raise 15% tax against imports of fine tobacco from India', falls within the scope of Congress' power". The law's mission doesn't say anything about a tax, just about making sexual activity with minors criminal offenses. A judge would literally have to abandon all pretense of interpreting rights and other complex laws and simply state, "BECAUSE I SAY SO!"
But they also gave money to Comcast, which means that maybe Verizon or AT&T can hit them up and get money.
If they dodged Comcast in that way, then all Verizon or AT&T could do is expend their money to get Netflix to expend money as well, which is not as attractive.
Why didn't Netflix get a colo with a data center already backboned on Comcast and use that, to avoid paying Comcast?
That sounds like AOL.