This is a big deal. If you use a browser on Windows that does NOT counter this, such as Internet Explorer, then you ARE vulnerable. I imagine Microsoft will come out with a special-purpose patch, but still, this is a pretty nasty issue.
Untrustworthy CAs have been a problem for a long time; we need mechanisms to address them. The terrible cert revocation system makes it even worse; you can't be sure that the certs are checked in many cases. Chrome's CRLSets are not the answer; they are not even the beginning of an answer. We need to fix the whole revocation system. Sadly, there hasn't been enough work or enough urgency on these problems; maybe this will light a fire under those efforts. I doubt it, but it's worth hoping.
The difference is that in a conspiracy someone plans to DO something unlawful, or cause someone else to do it... and not just talk about it. A "conspiracy" is "a secret plan by a group to do something unlawful or harmful". A fantasy is just the "activity of imagining things".
I'm glad that people are learning about this problem. Sadly, it's not new, it's been known for decades. CERT’s “Secure Coding” item MSC09-C (Character Encoding — Use Subset of ASCII for Safety) specifically discusses the vulnerabilities due to filenames. The Common Weakness Enumeration (CWE) includes 3 weaknesses related to filenames (CWE 78, CWE 73, and CWE 116), all of which are in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors.
My freely-available book on writing secure software has a whole section about filenames. And so on.
We need to fix the problems with Unix/Linux filenames, not just keep rediscovering them. In particular, ensuring that filenames had no control characters, no leading dashes, and used UTF-8 encoding would simplify developing correct programs. Most people writing software already follow these rules. We don't need to make it easy for attackers.
To be fair, the article itself does state that the 7.1B figure does not represent unique users or handsets in use. Instead, it says that "The number of unique users is now 4.5 Billion or 63% of all humans alive are actually users of mobile phones. The remaining 2.6 Billion accounts are second or third accounts for the same user... So 20% of us, one in five who has a mobile subscription or account, actually walks around with two phones (and at least two accounts)."
Lots of people I know have at least two phones. Heck, I personally have a "work phone" and a "personal phone". My company is a lot less worried about their data mixing with other stuff, especially when combined with additional sandboxing mechanisms like GOOD. It helps me, too. If some organizational data gets out, my employer can erase the phone without me worrying that they'll erase my stuff. Also, I'm a lot freer to install apps than I would be if my company controlled what could be installed on the device that also housed my company's data.
This isn't even unusual. Phones are small and cheap enough to have two. Software-based security mechanisms leak all the time; making things physically separate is far more effective if protecting data actually matters. Not everyone needs to do this, but it's fairly common when data confidentiality really matters.
OpenSSL was actually examined by a lot of tools, but they all missed Heartbleed.
My article How to Prevent the next Heartbleed lists approaches that could have found it. We need to improve how we examine this software so problems like this don't happen again.
But that's the point, we can and should take measures to prevent it. Even if we never eliminate all vulnerabilities, we can prevent many more vulnerabilities than we currently do.
Agreed, but not in C. You need to change C (and modify the code to use the functionality) or change programming language. The article does discuss switching languages.
The LLVM static analyzer finds this bug. So would warning about dead code, since the code past the point of the second goto...
Um, no. You're talking about the Apple "goto fail; goto fail;" vulnerability. That's a different vulnerability in a different program. They're both vulnerabilities in TLS/SSL implementations, but they are different programs.
Profiling w/ 100% code coverage would have caught this bug. - No, code coverage would not have worked in this case. Since the problem was that code was missing, you can run every line or branch without triggering the vulnerability. For more, see: http://www.dwheeler.com/essays...
Input fuzzing in the unit tests under memtest could have located this bug even faster. - No, not in this case. Fuzzers were countered because OpenSSL had its own set of memory allocators. When fuzzing you often are looking for crashes; to force buffer over-reads into a crash, the usual way to do that is to override memory allocation. Since OpenSSL managed its memory separately, the override had little useful effect. For more, see: http://www.dwheeler.com/essays...
I'm really glad you're trying to think of alternatives. However, when you say: 1). Initialize all allocated memory. Routinely and automatically.... They did. But the Heartbleed bug let you see currently-active memory. In particular, you have to have the private key available somewhere so you can use it.
Some of the weirdness was due to the spec itself (RFC 6520). I agree that error avoidance is better than parameter-checking, but it's not clear that parameter-checking could have been avoided in this case. But that's certainly worth checking out.
This referenced article is rediculous.
First of all, the title says "Downfall of the Roman Empire", but Caesar FOUNDED the Roman Empire, so clearly it did not cause the empire's fall. I suspect they meant the fall of the Roman REPUBLIC, which preceded the empire.
But it's still garbage. What most emperors wanted was power, not concrete buildings. The article doesn't even begin to make a connection between the two.
If you want more about the history of the (Western) Roman republic and empire, listen to AWESOME "The History of Rome" podcast: http://thehistoryofrome.typepa... It's fantastic.
There's no "app" for screenshots because it's built into Android itself, and has been since 4.0 (which was released many years ago). It's volume down + power button. Just Google for "Android screenshot".
This makes no sense. If you want to search for code, the obvious way to do it today is use Google or some other search engine. Tomorrow, the obvious way to do it... will be to use Google or some other search engine. You don't need a "federated search", you just need a good search engine. There are a number of code-specific search engines that already work today too, again, there's no need for one system to rule them all.
I think there's great advantage in having an OSS management system for managing OSS projects.
One big improvement would be to make organ donation the *default* when obtaining a driver's license in the US. That way, people could opt out, but most people just "accept the default"... and then far more organs would be available to save the living.
I've had better luck with Chromebooks. Cloud printers are now very common, and in many cases buying a new printer costs little and is a big improvement anyway. For a list of printers that can work this way, see: http://www.google.com/cloudpri... I hate trackpads anyway, and I've had excellent success with normal mice on a Chromebook. Apple components often don't like working with non-Apple components, that may be the problem there. And all built-in laptop speakers are bad; if it matters, get speakers, they're cheap.
This is very common in the military and in defense contractors, and it happens elsewhere too. There is a reason for it. Many of these organizations are worried about malicious stuff going in and/or exfiltration of non-public data going out. Employer MITM makes it easy to examine every packet for these kinds of things (to counter them). In the US, at least, it's generally accepted that employer equipment is owned by the employer, and thus they expressly have the authority to examine what goes over their own network... and as a condition of employment or computer use you probably signed something agreeing to this. I'm not a fan of this approach, but it certainly happens.
Open source software that implements crypto protocols (e.g., SSL or SSH) will (correctly!) report that there's a MITM attack. So if you want to actually *use* the software in such settings, someone has to configure the software to trust the MITM. Some admins will do this automatically. If not, you may need to do it yourself. E.G., on Firefox, install the organization's certificate.
You configure Linux systems to work in these environments, but since the certs are often files in Windows aka DOS aka CP/M format, you need to convert the files as well as put the into somewhere useful. Here's one way to deal with it.
On Fedora, given a bunch of.crt files, you can do this:
This is a good start. If "we the people" pay to develop software, then it makes sense to ensure that "we the people" can use it, improve it, and distribute those improvements by default. See http://freethecode.org/ for others who think that makes sense too.
The URL http://www.dwheeler.com/govern... has a longer list of software released by US governments (federal, state, or local) as open source software. It even identifies a few meta-lists like this one. I'm sure it's incomplete, but it shows that US governments do release open source software. I'd love to hear of other examples of such software (with URLs that prove that the government paid to develop or improve it).
GNU guile's built-in reader includes support for SRFI-105, so you can use infix expressions directly. In particular, you can use {...} instead of (...) and put the operator in the EVEN position, e.g., {n https://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html
If you want to eliminate more of the parens, you can use guile with SRFI-110, which provides support for indentation-sensitive semantics. An implementation is available with an MIT license. See more here: http://readable.sourceforge.net/
It's not complicated. It's simple. Upgrading a production system is a *big deal*, and in many places there is a long delay between updates. Enterprises will often pay big $$$ to NOT upgrade (other than security patches), because they want rock-solid stability much more than the latest hotness.
E.G., RHEL 5 and CentOS 5 are widely deployed, and will be used for some time to come as production systems. They only support older versions of Python2. Therefore, *useful* programs that need to run on these widely-used systems must be written to run on these older systems.
I believe this is for the Visual Basic 6 or less, not for "Visual Fred" which has the same name but mostly unrelated syntax and semantics. See: http://catb.org/jargon/html/V/Visual-Fred.html
I think you have to take those measures with large grains of salt, but it's certainly true that languages affect productivity.
I actually read the article (I know, you can't do that on Slashdot). It says DevShare is opt-in for developers, not opt-out, and that's what inserts the additional stuff in the executables. So were the GIMP folks just confused? It sounds like GIMP left over something that was in their control in the first place.
(No, I don't work for any of these folks.)
Slashdot Mirror
This is a big deal. If you use a browser on Windows that does NOT counter this, such as Internet Explorer, then you ARE vulnerable. I imagine Microsoft will come out with a special-purpose patch, but still, this is a pretty nasty issue.
Untrustworthy CAs have been a problem for a long time; we need mechanisms to address them. The terrible cert revocation system makes it even worse; you can't be sure that the certs are checked in many cases. Chrome's CRLSets are not the answer; they are not even the beginning of an answer. We need to fix the whole revocation system. Sadly, there hasn't been enough work or enough urgency on these problems; maybe this will light a fire under those efforts. I doubt it, but it's worth hoping.
Hopefully they will quickly submit a counter-notice.
The difference is that in a conspiracy someone plans to DO something unlawful, or cause someone else to do it... and not just talk about it. A "conspiracy" is "a secret plan by a group to do something unlawful or harmful". A fantasy is just the "activity of imagining things".
This is a really impressive start. It's not done, but they don't claim it is. It's responsive and does quite a bit.
I'm glad that people are learning about this problem. Sadly, it's not new, it's been known for decades. CERT’s “Secure Coding” item MSC09-C (Character Encoding — Use Subset of ASCII for Safety) specifically discusses the vulnerabilities due to filenames. The Common Weakness Enumeration (CWE) includes 3 weaknesses related to filenames (CWE 78, CWE 73, and CWE 116), all of which are in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors. My freely-available book on writing secure software has a whole section about filenames. And so on.
We need to fix the problems with Unix/Linux filenames, not just keep rediscovering them. In particular, ensuring that filenames had no control characters, no leading dashes, and used UTF-8 encoding would simplify developing correct programs. Most people writing software already follow these rules. We don't need to make it easy for attackers.
To be fair, the article itself does state that the 7.1B figure does not represent unique users or handsets in use. Instead, it says that "The number of unique users is now 4.5 Billion or 63% of all humans alive are actually users of mobile phones. The remaining 2.6 Billion accounts are second or third accounts for the same user... So 20% of us, one in five who has a mobile subscription or account, actually walks around with two phones (and at least two accounts)."
Lots of people I know have at least two phones. Heck, I personally have a "work phone" and a "personal phone". My company is a lot less worried about their data mixing with other stuff, especially when combined with additional sandboxing mechanisms like GOOD. It helps me, too. If some organizational data gets out, my employer can erase the phone without me worrying that they'll erase my stuff. Also, I'm a lot freer to install apps than I would be if my company controlled what could be installed on the device that also housed my company's data.
This isn't even unusual. Phones are small and cheap enough to have two. Software-based security mechanisms leak all the time; making things physically separate is far more effective if protecting data actually matters. Not everyone needs to do this, but it's fairly common when data confidentiality really matters.
OpenSSL was actually examined by a lot of tools, but they all missed Heartbleed. My article How to Prevent the next Heartbleed lists approaches that could have found it. We need to improve how we examine this software so problems like this don't happen again.
But that's the point, we can and should take measures to prevent it. Even if we never eliminate all vulnerabilities, we can prevent many more vulnerabilities than we currently do.
Agreed, but not in C. You need to change C (and modify the code to use the functionality) or change programming language. The article does discuss switching languages.
The LLVM static analyzer finds this bug. So would warning about dead code, since the code past the point of the second goto...
Um, no. You're talking about the Apple "goto fail; goto fail;" vulnerability. That's a different vulnerability in a different program. They're both vulnerabilities in TLS/SSL implementations, but they are different programs.
Profiling w/ 100% code coverage would have caught this bug. - No, code coverage would not have worked in this case. Since the problem was that code was missing, you can run every line or branch without triggering the vulnerability. For more, see: http://www.dwheeler.com/essays...
Input fuzzing in the unit tests under memtest could have located this bug even faster. - No, not in this case. Fuzzers were countered because OpenSSL had its own set of memory allocators. When fuzzing you often are looking for crashes; to force buffer over-reads into a crash, the usual way to do that is to override memory allocation. Since OpenSSL managed its memory separately, the override had little useful effect. For more, see: http://www.dwheeler.com/essays...
I'm really glad you're trying to think of alternatives. However, when you say: 1). Initialize all allocated memory. Routinely and automatically.... They did. But the Heartbleed bug let you see currently-active memory. In particular, you have to have the private key available somewhere so you can use it.
Some of the weirdness was due to the spec itself (RFC 6520). I agree that error avoidance is better than parameter-checking, but it's not clear that parameter-checking could have been avoided in this case. But that's certainly worth checking out.
This referenced article is rediculous. First of all, the title says "Downfall of the Roman Empire", but Caesar FOUNDED the Roman Empire, so clearly it did not cause the empire's fall. I suspect they meant the fall of the Roman REPUBLIC, which preceded the empire. But it's still garbage. What most emperors wanted was power, not concrete buildings. The article doesn't even begin to make a connection between the two. If you want more about the history of the (Western) Roman republic and empire, listen to AWESOME "The History of Rome" podcast: http://thehistoryofrome.typepa... It's fantastic.
There's no "app" for screenshots because it's built into Android itself, and has been since 4.0 (which was released many years ago). It's volume down + power button. Just Google for "Android screenshot".
This makes no sense. If you want to search for code, the obvious way to do it today is use Google or some other search engine. Tomorrow, the obvious way to do it... will be to use Google or some other search engine. You don't need a "federated search", you just need a good search engine. There are a number of code-specific search engines that already work today too, again, there's no need for one system to rule them all.
I think there's great advantage in having an OSS management system for managing OSS projects.
One big improvement would be to make organ donation the *default* when obtaining a driver's license in the US. That way, people could opt out, but most people just "accept the default"... and then far more organs would be available to save the living.
I've had better luck with Chromebooks. Cloud printers are now very common, and in many cases buying a new printer costs little and is a big improvement anyway. For a list of printers that can work this way, see: http://www.google.com/cloudpri... I hate trackpads anyway, and I've had excellent success with normal mice on a Chromebook. Apple components often don't like working with non-Apple components, that may be the problem there. And all built-in laptop speakers are bad; if it matters, get speakers, they're cheap.
This is very common in the military and in defense contractors, and it happens elsewhere too. There is a reason for it. Many of these organizations are worried about malicious stuff going in and/or exfiltration of non-public data going out. Employer MITM makes it easy to examine every packet for these kinds of things (to counter them). In the US, at least, it's generally accepted that employer equipment is owned by the employer, and thus they expressly have the authority to examine what goes over their own network... and as a condition of employment or computer use you probably signed something agreeing to this. I'm not a fan of this approach, but it certainly happens.
Open source software that implements crypto protocols (e.g., SSL or SSH) will (correctly!) report that there's a MITM attack. So if you want to actually *use* the software in such settings, someone has to configure the software to trust the MITM. Some admins will do this automatically. If not, you may need to do it yourself. E.G., on Firefox, install the organization's certificate.
You configure Linux systems to work in these environments, but since the certs are often files in Windows aka DOS aka CP/M format, you need to convert the files as well as put the into somewhere useful. Here's one way to deal with it.
On Fedora, given a bunch of .crt files, you can do this:
dos2unix *.crt ; cat *.crt >> /etc/pki/tls/certs/ca-bundle.crt
On Ubuntu, you can do this given a bunch of .cer files:
dos2unix *.cer ; rename 's/.cer$/.crt/' *.cer ; ca=/usr/share/ca-certificates ; mkdir -p $ca/MYORG ; cp *.crt $ca/MYORG ; cd $ca ; ls MYORG/* >> /etc/ca-certificates.conf ;
update-ca-certificates
You could avoid appending to the file if you want to, but I'll leave that as an exercise for the reader.
This is a good start. If "we the people" pay to develop software, then it makes sense to ensure that "we the people" can use it, improve it, and distribute those improvements by default. See http://freethecode.org/ for others who think that makes sense too.
The URL http://www.dwheeler.com/govern... has a longer list of software released by US governments (federal, state, or local) as open source software. It even identifies a few meta-lists like this one. I'm sure it's incomplete, but it shows that US governments do release open source software. I'd love to hear of other examples of such software (with URLs that prove that the government paid to develop or improve it).
GNU guile's built-in reader includes support for SRFI-105, so you can use infix expressions directly. In particular, you can use {...} instead of (...) and put the operator in the EVEN position, e.g., {n https://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html
If you want to eliminate more of the parens, you can use guile with SRFI-110, which provides support for indentation-sensitive semantics. An implementation is available with an MIT license. See more here: http://readable.sourceforge.net/
It's not complicated. It's simple. Upgrading a production system is a *big deal*, and in many places there is a long delay between updates. Enterprises will often pay big $$$ to NOT upgrade (other than security patches), because they want rock-solid stability much more than the latest hotness.
E.G., RHEL 5 and CentOS 5 are widely deployed, and will be used for some time to come as production systems. They only support older versions of Python2. Therefore, *useful* programs that need to run on these widely-used systems must be written to run on these older systems.
I believe this is for the Visual Basic 6 or less, not for "Visual Fred" which has the same name but mostly unrelated syntax and semantics. See: http://catb.org/jargon/html/V/Visual-Fred.html I think you have to take those measures with large grains of salt, but it's certainly true that languages affect productivity.
It's funny, but out of context. See: Jeff Atwood, “Regular Expressions: Now You Have Two Problems” June 27, 2008, http://www.codinghorror.com/blog/2008/06/regular-expressions-now-you-have-two-problems.html
I actually read the article (I know, you can't do that on Slashdot). It says DevShare is opt-in for developers, not opt-out, and that's what inserts the additional stuff in the executables. So were the GIMP folks just confused? It sounds like GIMP left over something that was in their control in the first place. (No, I don't work for any of these folks.)