Trusted and un-trusted vulnerability assessment

I read a article titled From SATAN to OVAL: The Evolution of Vulnerability Assessment today, and I really like the term "Trusted" and "un-trusted" vulnerability assessment.

As Dr. Gerhard Eschelbeck put in his article:
"Un-trusted vulnerability assessments simulate the scenario of an attacker without prior knowledge about the target system, while trusted assessments leverage credentials to log into the target systems for auditing configuration and patch information."

Trusted vulnerability assessment is kind of the trend that scanner vendors are doing. One example is MS baseline scanner, another is nessus (its plugins number growed from less then 2000 to more than 8000 in 2 years, most of the new ones are "local checks"). The reason behind it is obvious: this is way easier to implement and it works well in enterprise environment (also make it less likly to be used a hacking tool).

Security and Testing Conferences

Secure Programming Group at University of Oulu (Finland) maintained a very nice list of Security and Testing Conferences. I had tried to do same something on my little personal website when I was in school, but lost interest to update it after graduation:(

http://www.ee.oulu.fi/research/ouspg/sage/conferences/index.html

Building native C++ projects with NAnt

I have not tried nant for a long time because I thought(wrongly) it is just for .NET, and my daily job involves only native C++.

My current build process use MPC, devenv command line and batch script. I like MPC a lot(especially the idea of inheritance used the build process). MPC's template approach can help me to create .sln and .vcproj with very little effort.

Devenv.com is helpful as well, although it is a little bit slow. vcbuild.exe is faster, but there are some small issues I do not like (the devil is always in the details).

I uses batch script(.bat) to glue the build process together, but I really hate to program in this old awkward langage. I resisted to put more error handling because it can easily mess up the script.

So I decided to switch to nant after I found it can handle c++ project as well. Even though it takes me a while to figure it out, using nant is quiet easy. The solution task is great idea (know how to live peacefully with others is important:)): no need to write verbose build script and no need to wot worry about keeping it in sync with visual studio.

If all the environment variables are setup correctly (I will take about the tricks later), the build file can be as simple as this(and it is faster than devenv):

<?xml version="1.0" ?>
<project name="myproject" default="all" xmlns="http://nant.sf.net/schemas/nant.xsd">
 <target name="all" depends="debug, release" />

 <target name="debug">
  <solution solutionfile="myproject.sln" configuration="Debug" />
 </target>

 <target name="release">
  <solution solutionfile="myproject.sln" configuration="Release" />
 </target>
</project>

Unless you run nant from Visual Stuio 2003 Command Prompt, you may see lots of erros about missing headers and libs. This is because you need a few more environment varibles(PATH, INCLUDE and LIB). Visual studio will set them up for itself (see vcvars32.bat) and nant are not aware of them (it knows only system level environment varibles).

Nant supports setenv task so it looks like good place to go. But it will bloat the build file. Why not just use vcvars32.bat? If you are following the installation procedure of nant, you can just add a line into your nant.bat:

@echo off
@call "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\vsvars32.bat"
"C:\tools\nant-0.85-rc3\bin\NAnt.exe" %*

You can also use "HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun" so that vcvars32.bat is launched everytime cmd.exe is created. For cygwin users you know what to do:)

There is a small issue in the current release (0.85 Release Candidate 3): rc files can include c++ header files. Resource.h is one of them. And this practice uses it as well. But in the source code(nant-0.85-rc3\src\NAnt.VisualCpp\Tasks\RcTask.cs::NeedsCompiling), the date of the header files are not checked. So if you modified the include file, the resource will be rebuilt.

Btw, nant uses its own algorithm to calculate the dependencies between files, so you may see different compilation sequence between nant and devenv, it's even true for C# projetcs.

windbg beated VS.NET debugger

Our QA guy sent me a minidump file of crashed service and asked my help. The developer who wrote the program forgot to check in the full debug symbol file, but we do have the stripped .pdb file since we always ship it along with our product (following the advise of John Robbins).

I opened the minidump file with Visual Studio .NET debugger, but this time it did a terrible job reconstructing stack trace (later I find out the information it gave me is misleading, which is worse than useless). Well, I soon switched to windbg, and it showed me the correct result. The bug was found(printf again!) and fixed in less than 10 minutes, thanks to windbg.

Last time windbg beated VS.NET debugger on my system is a program deadlocked in the system space and VS.NET debugger can not break into it.

Use devenv in cygwin

I use cygwin as a better shell, not a development environment. Cygwin can do an excellent job as a replacement of cmd.exe(of course it can do much much more), and I like it very much.

There is a few corner cases where command behaves differently in cygwin and cmd.exe, for example:

When you type 'devenv' in cmd.exe, it will bring up devenv.com, which is expected since Windows prefers .com to .exe if both exist in the user's PATH (see the article in C++ QA column of the February 2004 issue of MSDN Magazine). But when you type 'devenv' in cygwin, it will launch devenv.exe instead, the project will get compiled anyway but you can no longer see the output of the compilation process.

"Files and Folders" View of InstallShield

InstallShield gives you a nice "Files and Folders" view(Application Data) and lets you add new components as drag and drop files. It is very easy for a developer to jumpstart an installation project without reading any documents. But it does not mean you can totally forget the existence of component table.

Recently I find out there are lots of duplicated components in my project, they have the same name but different suffix, for example: mylib.dll1, mylib.dll2, mylib.dll3. It confused me for a while because I am not sure if I should delete some of them(as a developer, removing duplication becomes my habit:)).

Until recently I find out that if you delete files from "Files and Folders" view, they won't be removed from the component table. And after you add the same file again, InstallShield will create a new component named yourfile.dll1(.dll2 if .dll1 exists already). By the way, they will be considered to be different components since the component code changed.

Maybe InstallShield thinks it's nice to keep them for people don't use version control:)

Give Up Microsoft Visual C++ Toolkit 2003

I tried to get some free lunch from Microsoft Visual C++ Toolkit 2003, but finally gives up. There are lots of missing pieces, most of them can be fixed by downloading other packages, but it is tedious and may not be allowed.

There are a few problems I encountered:

1. Only static-link C/C++ libraries are available, so you can not use /MD, /MDD by default. this link introduced a hack but as mentioned in the same article it has its limits.

2. Do not have a build system. It's easy to generate solution(.sln) and project (.vcproj) with MPC, and we can use vcbuild.exe to compile them. But soon you will find out vcbuild requires several dlls from VS C++ 2003, even through you can copy some dlls from there to make it work(see this article). So you have to purchase a copy of VS C++ anyway.