Author: jared

Posted on

Article: Crash-only software

Crash-only software: More than meets the eye
by Valerie Henson July 12, 2006:
http://lwn.net/Articles/191059/

Properly implemented, crash-only software produces higher quality, more
reliable code; poorly understood it results in lazy programming. Probably
the most common misconception is the idea that writing crash-only software
is that it allows you to take shortcuts when writing and designing your
code. Wake up, Sleeping Beauty, there ain’t no such thing as a free lunch.
But you can get a more reliable, easier to debug system if you rigorously
apply the principles of crash-only design.

Posted on

The software patent monster impedes innovation

Bruce Perens tells us that patents impede innovation his article, The Monster Arrives: Software Patent Lawsuits Against Open Source Developers:

Patents were created as a means to get inventors to disclose their inventions, rather than keep them secret. The disclosure of an invention was supposed to allow others to more easily build on that invention, thus creating more inventions. But the patent system has evolved into something useless for the purpose of disclosure, and engineers are now instructed to avoid looking at other companies’ patents because if the victim of a patent lawsuit can be shown to have known of a patent, the award to the patent holder is tripled. There have been no reliable studies that show software patenting to have encouraged innovation, and there is much evidence that they actually impede it.

Posted on

Mongrel web server

Here’s an interview with Zed Shaw, the author of the Mongrel web server — a web server for the Ruby programming language that is good for use in combination with Ruby on Rails and other Ruby-based web-app frameworks. It’s interesting in that it’s fast, secure, cross-platform, and it’s not a heavyweight solution (compared to Apache). Why is it more secure than Apache at the HTTP protocol level? Mongrel utilizes the Ragel State Machine Compiler
 to generate the protocol parser, “and that is very strict and seems to block a huge number of attack attempts simply because it is so exacting.”

Posted on

Hard Drive Encryption: PGP Disk, LUKS, BitLocker

Why encrypt a hard drive? It makes it safer to dispose of an old hard disk… your data won’t fall into the wrong hands. This only matters if you want data to remain confidential. Laptop owners should consider using hard disk encryption.

When is it a bad idea to encrypt a hard drive? First, if you have a dual-boot computer (Linux and Windows), and you want Linux to be able to access all of the data on the Windows drive. Second, when the data confidentiality is of low concern and the data availability is of high importance.

Bruce Schneier writes about Microsoft BitLocker, which will be available in Windows Vista:

BitLocker Drive Encryption is a new security feature in Windows Vista, designed to work with the Trusted Platform Module (TPM). Basically, it encrypts the C drive with a computer-generated key. In its basic mode, an attacker can still access the data on the drive by guessing the user’s password, but would not be able to get at the drive by booting the disk up using another operating system, or removing the drive and attaching it to another computer.

PGP Disk is a current solution — no need to wait for Vista. On Linux, there are many solutions. The most current is LUKS and dm-crypt:

Apparently, HAL in Fedora recognizes LUKS volumes. It’s also possible to encrypt only your home directory with LUKS.

Update 5 June 2006

See also http://www.truecrypt.org/ and Wikipedia’s guide to disk encryption software.

Posted on

Security Myths and Passwords

Professor Eugene Spafford “is one of the most senior and recognized leaders in the field of computing.” Here’s what he has to say about password security.


http://www.cerias.purdue.edu/weblogs/spaf/general/post-30

In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.

Read the article for more details.

Posted on

Skype insecure

I was reading about Ekiga (Linux VoIP application) at
LWN and stumbled across this mention of
Skype:

Worth mentioning is the proprietary Skype protocol, which has some
serious security implications, according to what researchers presented
(PDF) at the Black Hat Europe 2006 conference. Skype clients can be
abused for the purpose of port scanning, distributed Denial of Service
(dDoS) attacks and other unpleasant things.

The PDF says that although the Skype technology is clever, it is
“Impossible to protect from attacks”.

LWN reader “tajyrink” says that Skype “works around [NAT] by being a
P2P program, not just a VoIP program, by using ruthlessly the bandwidth
of other users even without them knowing about it.”

Posted on

Article: Innovative ways to fool people

Innovative ways to fool people
Scott Granneman, 2006-05-04
http://www.securityfocus.com/print/columnists/401

Scott Granneman’s latest column looks at recent security examples where people have been fooled in increasingly innovative ways: from keyloggers used in a massive bank heist and new Trojans that encrypt data and request ransom money, to real financial rip-offs that extend out from online virtual gaming worlds like World of Warcraft.

It’s a fascinating read. Here’s an exerpt:

We now have computer sweatshops appearing in China and Mexico, in which
young men are paid a few dollars per day (or less) to sit and play games
like World of Warcraft and EverQuest for about 12 hours a day,
performing often mind-numbing tasks in order to create virtual wealth.

It was therefore inevitable that bad guys would see an opportunity to
steal money in settings like this. Now someone has.

Posted on

Why migrate a C++ project to Visual Studio 2005?

New and better tools are usually a good thing. So it is when moving from Visual Studio 2003 to the 2005 edition. Advantages of moving C++ development to Visual Studio 2005, Team Edition Developer include…

  1. Global/shared property sheets allow developers to change a setting in one place and have it apply to all projects. This makes it vastly easier to add new include paths and libraries, etc.
  2. New /analyze static analysis option goes the extra mile in identifying bugs such as buffer overflow, memory leaks, failure to check return types, etc. This feature is only available in VS 2005 Team Edition Developer.
  3. Better debugger supports tracepoints and displays STL containers in a human-readable format! See http://blogs.msdn.com/andypennell/archive/2004/06/29/169002.aspx for more information.
  4. Improved remote debugging.
  5. More standards-compliant C++ compiler. See http://msdn2.microsoft.com/en-us/library/ms177253(vs.80).aspx
  6. Built-in profiler.
  7. Const-correctness checks in functions such as strchr, strstr, etc. help identify and prevent bugs.
  8. Organize sub-projects into solution folders.
  9. Can substitute more secure versions of strcpy, strcat, etc. automatically under certain conditions if we define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES. There’s also _CRT_SECURE_NO_DEPRECATE.
  10. More and better warnings.
  11. Dependency checking is faster. This means, for example, that cleaning a solution is much faster than with VS 2003.
  12. Stack smashing protection (the /GS flag) is more robust.
  13. printf family of functions support the C99 Standard of “%ll” and “%ull” for 64 bit integers in addition to the non-portable, Microsoft-only VS2003 “%I64d” syntax.

Costs of migrating to VS 2005:

  1. Compiled code size is slightly larger.
  2. The IDE requires more memory to run.
  3. Third party libraries and libc
  4. Template code may need to be modified.

Additional resources:

Migration Strategy

It’s usually not a good idea to migrate a code base immediately, although it could be good way to anger management. Here’s what I recommend:

  1. Copy your top-level solution mysolution.sln to mysolution.vs2005.sln.
  2. Copy all sub-projects *.vcproj to *.vs2005.vcproj.
  3. Edit mysolution.vs2005.sln and chang all .vcproj references to .vs2005.vcproj.
  4. Open mysolution.vs2005.sln in VS 2005. It will migrate the project automatically.
  5. Add the new solution and project files to your source control system (Subversion, Perforce, CVS). This way, you won’t affect the day-to-day development operations of the rest of your team. You could write a script to automate the above steps so that it is easier to keep in-sync with the additions, renames and removals of includes, source, and so on from the VS 2003 solution.
  6. Compile and fix errors gradually.
    • You may need a new version of Microsoft’s WTL, which is backwards compatible with VS 2003.
    • You may need to fix template syntax issues.
    • Fix const-correctness issues.

Eventually your team will become comfortable with VS 2005, and you can switch.