Comcast is my ISP, and on Wednesday, some email started having trouble getting to me. It turns out that comcast.net was temporarily hijacked using a social engineering trick.
Category Archives: Security
Open Source Security report from Coverity
Coverity has published it’s Open Source Scan Report 2008, which details the security status of several open source projects. Here’s my summary:
- The overall security of open source projects is improving.
- There’s a linear relationship between the amount of code and the amount of bugs.
- Surprisingly, there’s no relation between function length and defect density.
Projects with exceptionally low defect density include Amanda, NTP, OpenPAM, OpenVPN, Perl, PHP, Python, TCL, Postfix, Samba, curl, libvorbis and vim.
The top two security defects are
- NULL pointer dereference
- Resource leak
I got to preview Coverity Prevent at a previous job, and it rocks at finding real bugs in code, with a very low rate of false positives.
Security vs Privacy is false dichotomy
Jon Stokes, Senior Editor, Ars Technica reported on the following:
“We have a saying in this business: ‘Privacy and security are a zero-sum game.’ ” Thus spake security consultant Ed Giorgio in a widely quoted New Yorker article on the U.S. intelligence community’s plans to vacuum up and sift through everything that flies across the wires.
Security expert Bruce Schiner wrote a Wired article addressing the false dichotomy between security and privacy:
I’m sure they have that saying in their business. And it’s precisely why, when people in their business are in charge of government, it becomes a police state.
The debate isn’t security versus privacy. It’s liberty versus control.
“Privacy no longer can mean anonymity,” says Donald Kerr, principal deputy director of national intelligence. “Instead, it should mean that government and businesses properly safeguard people’s private communications and financial information.” Did you catch that? You’re expected to give up control of your privacy to others, who — presumably — get to decide how much of it you deserve. That’s what loss of liberty looks like.
Returning to John Stokes, who said:
The story of Fidencio Estrada, a drug runner who bribed Florida Customs agent Rafael Pacheco to access multiple federal law-enforcement databases on his behalf, suggests that when it comes to the government collecting data on innocent civilians for law-enforcement purposes, privacy and security are essentially the same thing.
Disk Encryption: Not as secure as I thought
Apparently, it’s easier than I thought to recover disk encryption keys from a stolen laptop computer. The attack works against “several popular disk encryption systems: BitLocker (a feature of Windows Vista), FileVault (a feature of Mac OS X), dm-crypt (a feature of Linux), and TrueCrypt”. Watch the demonstration video at http://citp.princeton.edu/memory/.
The root of the problem lies in an unexpected property of today’s DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn’t so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.
Encrypting a disk drive does increase the confidentiality of data. It’s just not as secure as once thought.
Sidenote: Software and hardware based key loggers can reduce the security of encryption as well.
Security Lessons from Dick Marcinko
In January, Dick Marchinko spoke to my company. Here are some of the lessons that I drew from his hard-to-follow speech:
Most importantly, he said, there is no substitute for human intelligence.
Attackers can…
- defeat security systems, such as locks, by replacing them with their own security system in advance of a break-in. Security response will trust in their security system to help catch or contain attackers, not realizing that it was replaced and turned to the service of the attacker.
- use decoys to mislead security response. For example, crews might diffuse one bomb, and they forget to look for a second one.
- attack during noisy, chaotic, busy times, like shift-change. (My note: Hackers like to hide their malware on busy networks and on busy file servers, such as in university or ISP networks.)
- trip alarms to assess response capabilities. Once assessed, booby-trap the response capabilities so they are ineffective.
- evade security systems. TSA secures airports from passengers, but what about security airport construction sites and access? America’s ports and waterways are largely unprotected.
Javascript = poor security
Jake Edge writes about “Web security vulnerabilities and Javascript“:
Various recent, unrelated security issues seem to have a common thread: Javascript.
This has been true for the past several years, and it’s not restricted to Javascript — it has happened with Flash. Our browsers suck down executable code from nearly every web site we visit, and run it. It enables a richer web browsing experience. Although JavaScript, and to a lesser extent, Flash, are somewhat restricted in what they can run on our computers, it opens the potential for abuse. And they have been abused, again and again.
What solutions exist?
- Stick head in sand.
- Wait for web site owners and browser manufactures to fix the security problems. And wait. And wait. And wait some more.
- Use Firefox and the NoScript extension, which disables JavaScript, Flash, Silverlight and other executable code from running. It’s easy to enable JavaScript when needed.
NoScript can turn web browsing into a painful experience. Some web sites don’t function properly without JavaScript enabled. Functionality breakage may be subtle. I once bought movie tickets for the wrong day because I had JavaScript disabled. I still use NoScript.
NoScript has advantages beyond security: I see fewer annoying animated ads, making many web sites more readable.
Internet Explorer more secure than Firefox?
In the past, I’ve recommended to friends and family that they run Firefox instead of Internet Explorer to gain better security and usability on Windows systems. I’m re-evaluating that stance now that I’ve learned about a new feature of Windows Vista that restricts Internet Explorer and runs it inside of a jail. It’s called Protected Mode, or Mandatory Integrity Control, and it means that that spyware and adware are less likely to infect a Vista computer.
As far as I know, Firefox doesn’t (yet) run inside the “jail”, so Internet Explorer is probably the more secure choice — yet another reason to admire the technical engineering effort that went into Windows Vista.
Despite the improved security of IE 7 in Vista, I enjoy the usability of Firefox, including the ability to disable JavaScript from running by default, using the NoScript extension extension. Does anyone know whether there’s a NoScript extension available for Internet Explorer? If not, I’m sticking with Firefox.
FreeNX and SELinux
As I mentioned earlier, upgrading from Fedora 6 to Fedora 7 broke FreeNX. A temporary solution was to disable SELinux. Here's what allowed me to re-enable SELinux. First, I read the RHEL 5 SELinux guide to building a local policy module. Next, I ran the following commands, as root:
setenforce Enforcing
/etc/init.d/auditd stop
mv /var/log/audit/audit.log /var/log/audit.log.old
/etc/init.d/auditd start
At this point, I used an NX client to attempt to connect to my server, which failed. Then I did this:
cd /etc/selinux
cat /var/log/audit/audit.log | audit2allow -M freenx
semodule -i freenx.pp
At that point, my NX client allowed me to connect to the server. Here's the freenx.te file that audit2allow created:
module freenx 1.0;
require {
type unconfined_t;
type lib_t;
class file execmod;
}
#============= unconfined_t ==============
allow unconfined_t lib_t:file execmod;
Security quotes
"Security systems are never value-neutral; they move power in varying degrees to one set of players from another." -- Bruce Schneier, Beyond Fear p. 35
"People exaggerate spectacular but rare risks and downplay common risks". -- Bruce Schneier, Beyond Fear p. 26
"Technology is generally an enabler, allowing people to do things. Security is the opposite: It tries to prevent something... That's why technology doesn't work in security the way it does elsewhere, and why an overreliance on technology often leads to bad security, or even to the opposite of security." -- Bruce Schneier, Beyond Fear p. 13
Stages of Security in the life of computer software
Is your client-server software secure? You may be surprised to find that even mature software, sporting the use of standard encryption, could be putting your mission-critical data at risk. Why is that? It has to do with economics and the lifecycle of software. Here are the stages.
Prototype. No one cares about the security of the client-server communication.
First release. Althought the system (likely little more than an improved prototype) has been shipped, it may not be usable, and if it is, it lacks mission-critical features. Security is low on the priority list. If encryption and authentication were implemented, it is most likely minimal, brittle and insufficient. If the security is robust, the product is not functional and likely never will be because the ISV will go out of business.
Second or third release. If the ISV has survived long enough to release a second or third version, customers likely demanded the use of standard encryption. In the old days (the 1990s), this means the ISV would have switched from XOR "encryption" to DES or 3DES. These days, standard encryption probably means use of SSL/TLS without certificate checks. Note that customers probably won't ask about the security of the authentication mechanisms.
Unfortunately, use of a standard encryption algorithm doesn't mean communication is secure. Software is likely to be vulnerable to man-in-the-middle attacks and have authentication bugs. The customer isn't likely to know this, and neither is the ISV. If the ISV does know, they won't fix the problems. This shouldn't be surprising -- the risk tolerance is different for the ISV versus their customers. The software vendor isn't the one that is going to suffer losses due to information disclosure or breach of integrity.
At this stage, customers usually apply more pressure to implement new features than to focus on security. Of course, this is based on ignorance of the actual situation. The vendor isn't likely to want to pay the price to improve security... unless the customer knows and applies pressure to get it fixed.
Eventually, a security-conscious customer (i.e. a financial institution or a government) hires someone to evaluate the software, and they start asking hard questions of the ISV. Most of the ISV's software engineers won't know the answers because the security mechanism is transparent to their daily work -- it stays out of sight, and out of mind. Eventually, people figure out that the encryption is vulnerable to man-in-the-middle attacks or authentication bugs. At first, customers may be reluctant to believe that the security holes are serious, and then they will panic. They will apply pressure to the ISV to get it fixed.
Take-away points:
- SSL without certificate checks is vulnerable to Man in the Middle attacks.
- Almost no ISV gets encryption right the first time, and they won't fix problems unless their feet are held to the fire.