Forgot your password?

Comment: Old problem. Let's fix it. (Score 1) 215

by dwheeler (#47338317) Attached to: Exploiting Wildcards On Linux/Unix

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.

Comment: Re:Sanity check (Score 1) 197

by dwheeler (#46990705) Attached to: 7.1 Billion People, 7.1 Billion Mobile Phone Accounts Activated

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)."

Comment: Common situation: Work phone + personal phone (Score 1) 197

by dwheeler (#46990527) Attached to: 7.1 Billion People, 7.1 Billion Mobile Phone Accounts Activated

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.

Comment: Re:The LLVM static analyzer finds this bug. (Score 1) 231

by dwheeler (#46912335) Attached to: How To Prevent the Next Heartbleed

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.

Comment: Re:Input fuzzing, if you know what's good for you. (Score 1) 231

by dwheeler (#46912325) Attached to: How To Prevent the Next Heartbleed

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:

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:

Comment: Re:Too much reliance upon testing tools (Score 1) 231

by dwheeler (#46912283) Attached to: How To Prevent the Next Heartbleed

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.

Comment: Rediculous (Score 4, Interesting) 384

by dwheeler (#46859473) Attached to: How Concrete Contributed To the Downfall of the Roman Empire
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.

Support Mental Health. Or I'll kill you.