Yeah, car design is where you implement waterfall. Agile? In long-term engineering? Hah. No. The risk of change as you make incremental delivery is extremely low; agile just adds overhead.
Engineer's ethical responsibility is to not release a part he knows is faulty.
How a non-faulty part gets released isn't the engineer's responsibility. It's not part of their ethical behavior. All an engineer is supposed to do is look at a rocket ship, decide that it can't launch if the primary fuel tank seals are below 42F, and complain loudly that you absolutely cannot clear the customer to launch "because of triple-backup systems" below 42F because it will not "probably be okay". They don't have to care that these new seals have the same part number as the old seals.
The accusation is not fixed: they say he *might* have tried to re-engineer the switch without changing the part number. I want explanation of this. Maybe he suggested new design for part #11775 and someone said "it's released, we need a new part number" "oh right". Maybe he's a fucking project manager and didn't, at the time, understand that new designs to replace existing parts get new part numbers--I know that my steering column's ignition switch is part #XXX, and if it changes... it never occurred to me that the part number may change; I thought that minor revisions were the same part number (this seems to be standard practice--look at part number WRT54G v1 v1.1 v2 v4 v7).
You and Harvard don't understand how the market works. They bought securities. That means that no money went to the oil companies; money went to other investors. It's a wealth-transfer scheme.
These are people who are so fucking out of touch with reality that they think buying stocks means putting money into the hands of the companies whose stocks you buy. I've seen people on Slashdot say they invest in stocks for companies they want to support, and that's hilariously stupid. You bought $3000 of SIRI? That's funny. Do you know how much of that purchase went to SIRI? $0! They got all their money when they went IPO!
A divestment might hurt the stock price. So let's say Harvard sells $50 million of XOM. Exxon Mobil's stock price plummets. Exxon's board then buys back a ton of the stock. A few weeks later, the stock price comes back up; Exxon-Mobil is now better vested in its own stock, has more control, and is better able to capitalize by issuing new stock.
Are these stock market investments? Commodity futures? Or business partnerships where pulling their bonds removes money from the business?
If they're pulling investments in securities, the companies they're divesting from don't suffer any impact nor gain any benefit from Harvard's investment behavior.
You don't need to be working as a PM. You need to apply the PM process domains to your work. I do this all the time. When given a major task to accomplish, I evaluate its complexity. If it's project-scale, I do it. Migrating a bunch of hosted web sites: technically each is a project; however I consider them as operations after the first, and most technically each is a PHASE in a project (migrating entirely off of one server onto a cluster running different software). It's part of a larger program which involved several projects I carried out all by myself.
If you document these things, you can make the argument that you have the hours. The PMI explicitly accepts this: if you are applying the Project Management process groups appropriately, you are executing project management.
One of the sites I need to migrate is big and complex, behaves entirely differently from any other site, affects every other site when it's altered, and is built out of multiple individual sites functioning as one unit. This will require a different strategy. Right now I'm going over to the Web team to discuss this, to gather information about how it works so I can produce requirements and make sure I have people to communicate with each step of the way. It'll be iterative deliverable (agile) most likely, since I think I can actually deliver this in pieces.
I haven't been documenting this because I do 6 of these a day (hence why I consider this operations); although the original development of the process to do this involved some 80 hours of work and planning on top of that. A new process is a project deliverable.
You would be surprised what a CAPM gets you. I don't need $150k, but I can pass interviews (I flirt with recruiters and poke my head into an interview once in a while, but I just come back convinced I should stay where I am for now) and I don't even have the certification. When I have the cert, man, I'll be able to back it up in interview.
Polish your negotiation skills a bit. Tres Roeder's black book, A Sixth Sense for Project Management, is valid. Also, if the CAPM seems useless to you, you may want to look into growing a spine; hiring managers are taking advantage of your inability to negotiate a proper salary. I got hired into my job with zero direct experience, although I came from security to sysadmin and systems engineering.
How would it not exist? You'd still copy 64KB of RAM to a 64KB validly-allocated buffer. If your memory allocator uses brk() (i.e. pmalloc on glibc, kmalloc on freebsd), you're vulnerable.
IT people always look down on all the other morons and retards staffed in the building. They're stupid enough to look up to us, after all. Dumb bitches in HR, accounting, finance, lawyers who don't know a fucking thing about anything except legal bullshittery, CEOs and executives who can't find their ass with both hands.
Yeah uh, I've run an income statement. Would you like to try? When you finish crying, you can come suck my dick.
We need executives. My company doesn't have all the ones it needs, and they don't realize it, and we have risk problems. Severe risk problems from not having a CISO. Wasteful spending and excess work and ineffective output from not having a PMO with a Manager of Projects. Because of our market, basic business decisions--not just internal IT ones--would benefit from a CTO to help the CISO figure out how the fuck to handle market risks that will impact us severely. These people create top-down business strategy and establish what management gets hired to run what branches of operations.
HR goes through shit that would break my brain. Once. Then I'd absorb the process and handle it with great skill. Neuroplasticity is fucking awesome, after all. But seriously, god damn, have you ever tried that PHR test?
Miners have to decide if they want to go with stuff like water elevator or sub-level cave or whatever, which at a glance can appear roughly equivalent in terms of ore extraction, cost, and safety. Then you run a bunch of simulations and analysis and you find that doing a simple sub-level cave mine to pull ore pillars from a mined-out mine costs more, returns less, nets you half as much profit, and puts your people at a 30% higher risk of fatal death than doing a water elevator WITH sub-level cave. Then the damn miners have to figure out how to excavate a sub-level cave without collapsing it on themselves, and they have to pipe water into it without it getting soggy somewhere and collapsing on them.
Coal miners are going to translate either to construction or some branch of engineering. And I will be fucking glad when they're building bridges, because these are people who look at shit and go, "Oh hell no, you see this shit? No see, there's stress channels here, and this all comes to a focal point here, and like... wind and seismic activity from people walking over it or cars driving will create a pressure build-up that will lead to buckling and catastrophic failure. We can't use this design, people will die!" Because they've been there, they've held a hammer and looked at a rock in a wall, and they've looked up and gone, "... uh, wait, this shit will collapse on my head and kill me if we do this."
You learn to take pride in quality work when shit work is 99% likely to crush you to death.
We could use more PMs, but we have another problem: most PMs are terrible; and, although you can apply PM effectively to anything, you are a hell of a lot more effective if you have foundational knowledge of the project's domain.
Miyomoto Musashi said that a foreman must know all aspects of a carpenter: once the carpenter has lain floors, and built furniture, and carved designs and cut wedges and doors and columns, he can be a foreman. A good foreman can move from carpentry to a steel factory; but he will need to rely on experienced steel mill workers to explain a lot of things to him, and to help him work with the inexperienced and get them on track. A foreman who has been a steel worker will understand most of the base, will get new information from the experienced steel workers who know new processes and tools, and will be able to effectively direct the inexperienced to experienced steel workers and direct the experienced steel workers to get him trained in specific skills he is lacking in and "anything else you think he needs".
We can turn a coal worker into an ITPM. We will do much better turning IT people into ITPM.
Eventually, we get the same problem that we have with programmers: we have too fucking many STEM people, and the labor flood is creating high unemployment and low salaries. I'm trying to get in on these $160k PM salaries, but I expect them to drop to reasonable $90k salaries eventually. As well, I expect the job to turn into less of being the first guy awake, last guy to sleep, always there on weekends kind of thing and more of a reasonable position.
In short: project managers are like lubrication. Your engine needs it. The wrong lube will work better than no lube, but won't work well. The right lube works great, but you need enough of it. If you have too much of it, your engine dies.
If you thought up using a test case, you might look at the code and go, "o shit!" Or you might run your test case, look at the packet (does it return working data, even though it doesn't crash?) and go, "WTF IS THIS???" If your test case is "I ran it and didn't get SIGSEGV", your test case sucks.
So your position is that because you can't be 100% absolutely positive that your keys weren't compromised, you should regenerate them? Because that's what I understand you to be saying.
That's the advice being given in security circles. There's an exploit, it's mystical, it was released before patches, and someone could have silently stolen your keys. Please regenerate and reissue passwords, which may have been stolen.
You're talking about risk analysis--which is good, although you either don't know how to do it or you're abbreviating out the use of all the good analysis techniques--and I'm talking about the current risk behavior and how it would change. The prescribed risk behavior wouldn't change, because the keys are fundamentally broken: the risk of an RSA break is ungodly small, and the risk that your keys were vacuumed away at a whim is like comparing Jupiter to an ant. Jupiter is still tiny compared to Betelgeuse, I get that. We're talking 2^127 versus 2^16 here. 1/2^16 is really fucking small (99.998% chance you weren't hacked), but uh.
As for artificially pulling people toward a failsafe method: this is Schrodinger's cat. Your security is now imaginary, as the attacks don't show up in logs (unless you have Netwitness or something, or updated your NIDS). I can conjecture that our keys were probably not stolen here; the probability is low, maybe negligible, while the severity is ABSOLUTE. Mind you from a whole business perspective, using broken SSL keys for us is hilariously pointless--it's a "yeah, you should fix that" issue. From a perspective of "is our security broken?", we're talking about relying on something that may or may not be imaginary for this part of our security model.
10%/90%/99%/99.99% still is too much. It's not even mathematical; it's a statistical guess, and it's based on the idea that nobody bothered to try. You hope nobody cared, you're "low profile". Mostly the "probability" here is major conjecture about what kinds of people you're dealing with (not-Mossad) and how alert they are.
In this case, "a hardened malloc" indicates not using brk(). A long, long time ago, I started designing one based on mmap() and size classes. My inspiration was glibc's tendency to allocate large anonymous requests as mmap() anonymous segments; Hoard's non-locking multi-thread allocator (different per-thread allocation regions); and the theory that stuff allocated close together in time and of the same size class often was freed at the same time. realloc() became a compacting call as well.
I gave up because testing malloc() on Linux was hard. I hadn't figured out how to get away from the existing allocator.
It would require a hell of a lot of overhead. Faults into memory are extremely slow, and you can't just cache that there are millions of allocations. Further, a program may legitimately read all over RAM, potentially interleaving from two arrays (sort algorithms) or jumping back and forth in linked lists; analyzing this behavior would be nigh-impossible.
So? I'll take a 90% survival cancer over a 10% one.
You're not listening.
Look in your logs. There is, right now, a 90% chance that you probably haven't had your private keys stolen.
Of course, you can't verify that. You can't say for certain your private keys haven't been compromised.
My point was, and is, that the "Limited damage" case of Heartbleed is that there's a 99% chance that your keys weren't stolen. Of course, you can't verify that.
Let's say you posted your SSL keys on reddit, in public. Then you go back 1 second later and delete that post. It's deleted out of the reddit database. Probably, PROBABLY nobody saw that. The Reddit admins probably won't do crazy forensics to get them back. Probably nobody was packet sniffing Reddit and saw your keys.
That's what we're talking about here. The mitigated situation with Heartbleed is identical in nature to logging into your bank over plain HTTP using CAT5: nobody can sniff it in the air, and there are probably no MITM attacks happening on the backbone of the internet, so it's safe to run credit card transactions and online banking without HTTPS.
Look at the code, man. The code behaves exactly perfectly under non-exploit condition. If the payload is not smaller than the payload value, you don't read past the buffer.
It would be caught when someone figured out about the exploit. It would be caught when someone decided to test the TLS Heartbeat extension for invalid behavior when given a Payload value larger than the actual payload.
Coincidentally, it got caught when someone decided to give the TLS heartbeat extension a payload value larger than the actual payload.
It reads past the end of a buffer. Otherwise, it appears to handle allocations properly in this code. Other code in OpenSSL doesn't handle allocations properly--it's broken elsewhere.
Limited damage in the case of heartbleed are "you still don't know if your keys have been stolen, BUT it's less likely that they have." Schrodinger's cat with a longer radioactive half life is still unknown if alive or dead.
I conclude from this you think no SSL certificates were issued between, say, in 2013 or 2014. I'm curious what evidence you have for this. *eyeroll*
Why? Last week's live version of OpenSSL, latest in RHEL 6.5, latest in Ubuntu, latest in Fedora, were vulnerable. Anything currently in production on OpenSSL 1.0.1 anywhere is now suspect. That means if it was issued in 1995, has a 25 year expiration life, and is served from a machine using OpenSSL 1.0.1e, it's suspect. If it was issued two weeks ago and slapped on a new RHEL 6.5 box, it's suspect.
The heartbleed bug works by the user sending a payload which OpenSSL analyzes and determines to be of a length, like strlen(). Then it calls malloc() to allocate a buffer for that length, and copies that length in. 1 byte payload, malloc(1). Then it looks at the heartbeat handshake, which says, "Oh yeah, my payload is 64KB". Then it allocates a 64KB buffer and does a memcpy() of 64KB from that 1 byte buffer into the 64KB buffer.
Do you see the problem here? The server looks at the actual data and malloc()s something the size of the data. The client says, "The data is this big," and the server copies something the size the client dictates from where it allocated the data. Problem: what if the data is actually smaller?
Also, for good measure: The entire bug occurs between an allocation and a free. There actually isn't a free/realloc bug involved. Here, I'll show you.
Line 3974 starts the problem. Variable (p) is an array of bytes; the first 2 bytes are an unsigned int. n2s(p, payload) is essentially (payload = (unsigned int)(*p);). The (payload) value is an unsigned int carrying the length of the payload.
Line 3991 is your buffer allocation. And it looks like I'm wrong: it allocates a short buffer, which it writes outside of. This was not mentioned on the analysis I read. So a canary should catch this on free() when actively exploited, but not in non-exploit operation.
Line 3997 is the good part: it copies however many bytes you asked for from the SSL Heartbeat request into the payload buffer. That could be 64kb of shit, and the payload is 1 byte long.
Line 4002 sends the copied bytes back to the client. This is where the exploit succeeds.
Line 4009 is where the free() happens. If your glibc has canaries, it crashes here on exploit; this call works normally if you're not being exploited. It also works normally if your payload is short (although other errors may occur elsewhere).
Even so, it crashes IF AND ONLY IF it's being exploited, and only AFTER exploit returns data, and ONLY on write-bounds-checking allocators that look for a dead canary (which you'll actually know after the first exploit--on a forking process like Apache--and can supply with further exploits, so you can rapidly mine with one crash). If you're not testing it by asking for a bigger payload than you supply, you won't ever get this crash.
This isn't a double-free() issue. It's a bounds check issue.
Remember, payload is controlled by the attacker, and it's quite large at 64KB. If the actual HeartbeatMessage sent by the attacker only has a payload of, say, one byte, and its payload_length is a lie, then the above memcpy() will read beyond the end of the received HeartbeatMessage and start reading from the victim process's memory.
It's extremely predictable behavior: send a 1 byte payload, tell the server it's 64k, server allocates 1 byte and then copies 64k starting at the address of that 1 byte into a (separately allocated) 64KB buffer that's sent to the socket. The idea that using regular malloc() would detect non-malloc() things without doing fancy things to make non-malloc() things break is laughable. With canaries, malloc() can detect that you wrote off the edge when you free() it; but it can't detect that you read off the edge, unless it mmap()s anonymous memory boundaried by an unmapped page and right-aligns your allocation.
The buddy allocator in glibc has canaries (I think) and double-free() detection. It doesn't detect read-past-buffer. OpenBSD's probably does, at least I assume that's what they're saying.
Slashdot Mirror
Yeah, car design is where you implement waterfall. Agile? In long-term engineering? Hah. No. The risk of change as you make incremental delivery is extremely low; agile just adds overhead.
Engineer's ethical responsibility is to not release a part he knows is faulty.
How a non-faulty part gets released isn't the engineer's responsibility. It's not part of their ethical behavior. All an engineer is supposed to do is look at a rocket ship, decide that it can't launch if the primary fuel tank seals are below 42F, and complain loudly that you absolutely cannot clear the customer to launch "because of triple-backup systems" below 42F because it will not "probably be okay". They don't have to care that these new seals have the same part number as the old seals.
He's not an engineer, he's a Program Manager.
The accusation is not fixed: they say he *might* have tried to re-engineer the switch without changing the part number. I want explanation of this. Maybe he suggested new design for part #11775 and someone said "it's released, we need a new part number" "oh right". Maybe he's a fucking project manager and didn't, at the time, understand that new designs to replace existing parts get new part numbers--I know that my steering column's ignition switch is part #XXX, and if it changes ... it never occurred to me that the part number may change; I thought that minor revisions were the same part number (this seems to be standard practice--look at part number WRT54G v1 v1.1 v2 v4 v7).
They copied that trend from Ubuntu Unity.
You and Harvard don't understand how the market works. They bought securities. That means that no money went to the oil companies; money went to other investors. It's a wealth-transfer scheme.
These are people who are so fucking out of touch with reality that they think buying stocks means putting money into the hands of the companies whose stocks you buy. I've seen people on Slashdot say they invest in stocks for companies they want to support, and that's hilariously stupid. You bought $3000 of SIRI? That's funny. Do you know how much of that purchase went to SIRI? $0! They got all their money when they went IPO!
A divestment might hurt the stock price. So let's say Harvard sells $50 million of XOM. Exxon Mobil's stock price plummets. Exxon's board then buys back a ton of the stock. A few weeks later, the stock price comes back up; Exxon-Mobil is now better vested in its own stock, has more control, and is better able to capitalize by issuing new stock.
Are these stock market investments? Commodity futures? Or business partnerships where pulling their bonds removes money from the business?
If they're pulling investments in securities, the companies they're divesting from don't suffer any impact nor gain any benefit from Harvard's investment behavior.
4.5%
You don't need to be working as a PM. You need to apply the PM process domains to your work. I do this all the time. When given a major task to accomplish, I evaluate its complexity. If it's project-scale, I do it. Migrating a bunch of hosted web sites: technically each is a project; however I consider them as operations after the first, and most technically each is a PHASE in a project (migrating entirely off of one server onto a cluster running different software). It's part of a larger program which involved several projects I carried out all by myself.
If you document these things, you can make the argument that you have the hours. The PMI explicitly accepts this: if you are applying the Project Management process groups appropriately, you are executing project management.
One of the sites I need to migrate is big and complex, behaves entirely differently from any other site, affects every other site when it's altered, and is built out of multiple individual sites functioning as one unit. This will require a different strategy. Right now I'm going over to the Web team to discuss this, to gather information about how it works so I can produce requirements and make sure I have people to communicate with each step of the way. It'll be iterative deliverable (agile) most likely, since I think I can actually deliver this in pieces.
I haven't been documenting this because I do 6 of these a day (hence why I consider this operations); although the original development of the process to do this involved some 80 hours of work and planning on top of that. A new process is a project deliverable.
You would be surprised what a CAPM gets you. I don't need $150k, but I can pass interviews (I flirt with recruiters and poke my head into an interview once in a while, but I just come back convinced I should stay where I am for now) and I don't even have the certification. When I have the cert, man, I'll be able to back it up in interview.
Polish your negotiation skills a bit. Tres Roeder's black book, A Sixth Sense for Project Management, is valid. Also, if the CAPM seems useless to you, you may want to look into growing a spine; hiring managers are taking advantage of your inability to negotiate a proper salary. I got hired into my job with zero direct experience, although I came from security to sysadmin and systems engineering.
How would it not exist? You'd still copy 64KB of RAM to a 64KB validly-allocated buffer. If your memory allocator uses brk() (i.e. pmalloc on glibc, kmalloc on freebsd), you're vulnerable.
This is the IT trap.
IT people always look down on all the other morons and retards staffed in the building. They're stupid enough to look up to us, after all. Dumb bitches in HR, accounting, finance, lawyers who don't know a fucking thing about anything except legal bullshittery, CEOs and executives who can't find their ass with both hands.
Yeah uh, I've run an income statement. Would you like to try? When you finish crying, you can come suck my dick.
We need executives. My company doesn't have all the ones it needs, and they don't realize it, and we have risk problems. Severe risk problems from not having a CISO. Wasteful spending and excess work and ineffective output from not having a PMO with a Manager of Projects. Because of our market, basic business decisions--not just internal IT ones--would benefit from a CTO to help the CISO figure out how the fuck to handle market risks that will impact us severely. These people create top-down business strategy and establish what management gets hired to run what branches of operations.
HR goes through shit that would break my brain. Once. Then I'd absorb the process and handle it with great skill. Neuroplasticity is fucking awesome, after all. But seriously, god damn, have you ever tried that PHR test?
Miners have to decide if they want to go with stuff like water elevator or sub-level cave or whatever, which at a glance can appear roughly equivalent in terms of ore extraction, cost, and safety. Then you run a bunch of simulations and analysis and you find that doing a simple sub-level cave mine to pull ore pillars from a mined-out mine costs more, returns less, nets you half as much profit, and puts your people at a 30% higher risk of fatal death than doing a water elevator WITH sub-level cave. Then the damn miners have to figure out how to excavate a sub-level cave without collapsing it on themselves, and they have to pipe water into it without it getting soggy somewhere and collapsing on them.
Coal miners are going to translate either to construction or some branch of engineering. And I will be fucking glad when they're building bridges, because these are people who look at shit and go, "Oh hell no, you see this shit? No see, there's stress channels here, and this all comes to a focal point here, and like... wind and seismic activity from people walking over it or cars driving will create a pressure build-up that will lead to buckling and catastrophic failure. We can't use this design, people will die!" Because they've been there, they've held a hammer and looked at a rock in a wall, and they've looked up and gone, "... uh, wait, this shit will collapse on my head and kill me if we do this."
You learn to take pride in quality work when shit work is 99% likely to crush you to death.
We could use more PMs, but we have another problem: most PMs are terrible; and, although you can apply PM effectively to anything, you are a hell of a lot more effective if you have foundational knowledge of the project's domain.
Miyomoto Musashi said that a foreman must know all aspects of a carpenter: once the carpenter has lain floors, and built furniture, and carved designs and cut wedges and doors and columns, he can be a foreman. A good foreman can move from carpentry to a steel factory; but he will need to rely on experienced steel mill workers to explain a lot of things to him, and to help him work with the inexperienced and get them on track. A foreman who has been a steel worker will understand most of the base, will get new information from the experienced steel workers who know new processes and tools, and will be able to effectively direct the inexperienced to experienced steel workers and direct the experienced steel workers to get him trained in specific skills he is lacking in and "anything else you think he needs".
We can turn a coal worker into an ITPM. We will do much better turning IT people into ITPM.
Eventually, we get the same problem that we have with programmers: we have too fucking many STEM people, and the labor flood is creating high unemployment and low salaries. I'm trying to get in on these $160k PM salaries, but I expect them to drop to reasonable $90k salaries eventually. As well, I expect the job to turn into less of being the first guy awake, last guy to sleep, always there on weekends kind of thing and more of a reasonable position.
In short: project managers are like lubrication. Your engine needs it. The wrong lube will work better than no lube, but won't work well. The right lube works great, but you need enough of it. If you have too much of it, your engine dies.
If you thought up using a test case, you might look at the code and go, "o shit!" Or you might run your test case, look at the packet (does it return working data, even though it doesn't crash?) and go, "WTF IS THIS???" If your test case is "I ran it and didn't get SIGSEGV", your test case sucks.
So your position is that because you can't be 100% absolutely positive that your keys weren't compromised, you should regenerate them? Because that's what I understand you to be saying.
That's the advice being given in security circles. There's an exploit, it's mystical, it was released before patches, and someone could have silently stolen your keys. Please regenerate and reissue passwords, which may have been stolen.
You're talking about risk analysis--which is good, although you either don't know how to do it or you're abbreviating out the use of all the good analysis techniques--and I'm talking about the current risk behavior and how it would change. The prescribed risk behavior wouldn't change, because the keys are fundamentally broken: the risk of an RSA break is ungodly small, and the risk that your keys were vacuumed away at a whim is like comparing Jupiter to an ant. Jupiter is still tiny compared to Betelgeuse, I get that. We're talking 2^127 versus 2^16 here. 1/2^16 is really fucking small (99.998% chance you weren't hacked), but uh.
As for artificially pulling people toward a failsafe method: this is Schrodinger's cat. Your security is now imaginary, as the attacks don't show up in logs (unless you have Netwitness or something, or updated your NIDS). I can conjecture that our keys were probably not stolen here; the probability is low, maybe negligible, while the severity is ABSOLUTE. Mind you from a whole business perspective, using broken SSL keys for us is hilariously pointless--it's a "yeah, you should fix that" issue. From a perspective of "is our security broken?", we're talking about relying on something that may or may not be imaginary for this part of our security model.
10%/90%/99%/99.99% still is too much. It's not even mathematical; it's a statistical guess, and it's based on the idea that nobody bothered to try. You hope nobody cared, you're "low profile". Mostly the "probability" here is major conjecture about what kinds of people you're dealing with (not-Mossad) and how alert they are.
If either of those happened, we would have to assume that anything deployed in the vulnerable window was exploited. Same situation as today.
In this case, "a hardened malloc" indicates not using brk(). A long, long time ago, I started designing one based on mmap() and size classes. My inspiration was glibc's tendency to allocate large anonymous requests as mmap() anonymous segments; Hoard's non-locking multi-thread allocator (different per-thread allocation regions); and the theory that stuff allocated close together in time and of the same size class often was freed at the same time. realloc() became a compacting call as well.
I gave up because testing malloc() on Linux was hard. I hadn't figured out how to get away from the existing allocator.
Yes I misread the allocation. It's correct.
It would require a hell of a lot of overhead. Faults into memory are extremely slow, and you can't just cache that there are millions of allocations. Further, a program may legitimately read all over RAM, potentially interleaving from two arrays (sort algorithms) or jumping back and forth in linked lists; analyzing this behavior would be nigh-impossible.
So? I'll take a 90% survival cancer over a 10% one.
You're not listening.
Look in your logs. There is, right now, a 90% chance that you probably haven't had your private keys stolen.
Of course, you can't verify that. You can't say for certain your private keys haven't been compromised.
My point was, and is, that the "Limited damage" case of Heartbleed is that there's a 99% chance that your keys weren't stolen. Of course, you can't verify that.
Let's say you posted your SSL keys on reddit, in public. Then you go back 1 second later and delete that post. It's deleted out of the reddit database. Probably, PROBABLY nobody saw that. The Reddit admins probably won't do crazy forensics to get them back. Probably nobody was packet sniffing Reddit and saw your keys.
That's what we're talking about here. The mitigated situation with Heartbleed is identical in nature to logging into your bank over plain HTTP using CAT5: nobody can sniff it in the air, and there are probably no MITM attacks happening on the backbone of the internet, so it's safe to run credit card transactions and online banking without HTTPS.
Look at the code, man. The code behaves exactly perfectly under non-exploit condition. If the payload is not smaller than the payload value, you don't read past the buffer.
It would be caught when someone figured out about the exploit. It would be caught when someone decided to test the TLS Heartbeat extension for invalid behavior when given a Payload value larger than the actual payload.
Coincidentally, it got caught when someone decided to give the TLS heartbeat extension a payload value larger than the actual payload.
70% of Canadian health care costs are covered by private insurance.
It reads past the end of a buffer. Otherwise, it appears to handle allocations properly in this code. Other code in OpenSSL doesn't handle allocations properly--it's broken elsewhere.
Limited damage in the case of heartbleed are "you still don't know if your keys have been stolen, BUT it's less likely that they have." Schrodinger's cat with a longer radioactive half life is still unknown if alive or dead.
I conclude from this you think no SSL certificates were issued between, say, in 2013 or 2014. I'm curious what evidence you have for this. *eyeroll*
Why? Last week's live version of OpenSSL, latest in RHEL 6.5, latest in Ubuntu, latest in Fedora, were vulnerable. Anything currently in production on OpenSSL 1.0.1 anywhere is now suspect. That means if it was issued in 1995, has a 25 year expiration life, and is served from a machine using OpenSSL 1.0.1e, it's suspect. If it was issued two weeks ago and slapped on a new RHEL 6.5 box, it's suspect.
Detecting reads that aren't supposed to happen in some situations is really fucking hard. We only have page-granularity CPU facilities.
The heartbleed bug works by the user sending a payload which OpenSSL analyzes and determines to be of a length, like strlen(). Then it calls malloc() to allocate a buffer for that length, and copies that length in. 1 byte payload, malloc(1). Then it looks at the heartbeat handshake, which says, "Oh yeah, my payload is 64KB". Then it allocates a 64KB buffer and does a memcpy() of 64KB from that 1 byte buffer into the 64KB buffer.
Do you see the problem here? The server looks at the actual data and malloc()s something the size of the data. The client says, "The data is this big," and the server copies something the size the client dictates from where it allocated the data. Problem: what if the data is actually smaller?
Also, for good measure: The entire bug occurs between an allocation and a free. There actually isn't a free/realloc bug involved. Here, I'll show you.
This is the vulnerable code. Start on line 3963.
Line 3974 starts the problem. Variable (p) is an array of bytes; the first 2 bytes are an unsigned int. n2s(p, payload) is essentially (payload = (unsigned int)(*p);). The (payload) value is an unsigned int carrying the length of the payload.
Line 3991 is your buffer allocation. And it looks like I'm wrong: it allocates a short buffer, which it writes outside of. This was not mentioned on the analysis I read. So a canary should catch this on free() when actively exploited, but not in non-exploit operation.
Line 3997 is the good part: it copies however many bytes you asked for from the SSL Heartbeat request into the payload buffer. That could be 64kb of shit, and the payload is 1 byte long.
Line 4002 sends the copied bytes back to the client. This is where the exploit succeeds.
Line 4009 is where the free() happens. If your glibc has canaries, it crashes here on exploit; this call works normally if you're not being exploited. It also works normally if your payload is short (although other errors may occur elsewhere).
Even so, it crashes IF AND ONLY IF it's being exploited, and only AFTER exploit returns data, and ONLY on write-bounds-checking allocators that look for a dead canary (which you'll actually know after the first exploit--on a forking process like Apache--and can supply with further exploits, so you can rapidly mine with one crash). If you're not testing it by asking for a bigger payload than you supply, you won't ever get this crash.
This isn't a double-free() issue. It's a bounds check issue.
Try this analysis:
Remember, payload is controlled by the attacker, and it's quite large at 64KB. If the actual HeartbeatMessage sent by the attacker only has a payload of, say, one byte, and its payload_length is a lie, then the above memcpy() will read beyond the end of the received HeartbeatMessage and start reading from the victim process's memory.
It's extremely predictable behavior: send a 1 byte payload, tell the server it's 64k, server allocates 1 byte and then copies 64k starting at the address of that 1 byte into a (separately allocated) 64KB buffer that's sent to the socket. The idea that using regular malloc() would detect non-malloc() things without doing fancy things to make non-malloc() things break is laughable. With canaries, malloc() can detect that you wrote off the edge when you free() it; but it can't detect that you read off the edge, unless it mmap()s anonymous memory boundaried by an unmapped page and right-aligns your allocation.
The buddy allocator in glibc has canaries (I think) and double-free() detection. It doesn't detect read-past-buffer. OpenBSD's probably does, at least I assume that's what they're saying.