Security Myths, Part II
Monday, January 21st, 2008Okay, sorry about the delay on posting this one. I had some other priorities to take care of first.
Last time, I explained why antivirus is basically a sham. This week, I’m covering firewalls.
Firewalls are only a half myth, really. Generally, firewalls do as they should: block either incoming or outgoing connections (or both). But in order for people’s internet connections to be functional, firewalls have to have exceptions. Certain connections must be allowed to pass through the firewall, or the network is essentially rendered useless.
Problem #1: In the case of end-users, firewalls can end up causing confusing symptoms (for instance, Windows file sharing failing to work properly because of a denied connection). The typical user probably wouldn’t know why file sharing refused to work, and would eventually get frustrated and either give up on the task at hand or resort to an inappropriate means of sending files (such as email). An informed user would probably add an exception for that set of ports and allow Windows file sharing to function.
Problem #2: Unfortunately, exceptions are the second issue. Firewalls are blanket security that we can punch holes in when we need to. Exceptions mean that we’re selectively exposing ports that we probably shouldn’t for security reasons. Further, the Windows file sharing ports are the most exploited for security holes of any ports on Windows. Blaster, Sasser, Bagle, MyDoom, NetSky, and Sircam all used Windows file sharing ports for infection.
Problem #3: Open ports are really not the problem. The problem is poorly written software. Windows file sharing was exploited so many times because it was truly that badly written. So many security considerations were ignored. To Microsoft’s credit, they are now developing software in such a way that most buffer overflows are avoided. They’ve basically made their developers use their secure C functions (sprintf_s, strcpy_s, etc), lest they get a compiler error. I’ve seen this myself when visiting Microsoft.
But now we’re at the root of the problem: we’re covering up programmer errors by making those errors publicly inaccessible while reducing functionality. What really should be done? Programmers should thoroughly test their programs, and potentially even implement their own secure C functions (for non-Windows platforms). But unfortunately, we’re stuck with firewalls because programmers don’t write secure code.
I would love to hear any opinion you may have about this blog. Email me directly at steven@uplinklabs.net and let me know what’s on your mind!



