Secure Technical Implementation Guides


The awareness for cyber security increases not only since WannaCry last year. Especially companies which operate critical infrastructure are looking for certificates which are given to secure software products by trusted authorities. One of this authorities is the Department of Defense (DoD) which provides the Information Assurance Certification and Accreditation Process DIACAP [1].

Within this process your piece of software is put to the acid test to get certified. The verification of Secure Technical Implementation Guides STIGs [2] is an essential part of this. Such a STIG depicts a configuration standard for DoD accredited systems.

No matter if you want to deal with DoD or not when you want to deliver secure software you should have a look into the available STIGs [3]. A STIG is a collection of rules, requirements and settings for many different products and systems. Especially noteworthy is the Application Security and Development STIG. The current version 4 contains 290 entries. Each one is categorized in one of three severity levels. The first level describes rules whose contempt may lead to direct loss of Confidentiality, Integrity or Availability (CIA). The second one has potential for loss and the last one may degrade protection measures. The CIA triad is a well known model in information security. It stands for the three most important protection goals.

Each entry contains a detailed description of the problem as well as an explanation what might be checked during the accreditation process. You might use this to validate your own application.

When you have downloaded a STIG you can view it in the web browser of your choice or you can use the STIG Viewer [4]. The major benefit of this application is the possibility to create a checklist. In such a list you can mark rules as “violated” or “no finding”. You can also adopt the severity to your needs

STIGViewer

Windows Subsystem for Linux


I never paid too much attention to the Windows Subsystem for Linux (WSL). But recently I wanted to do some gbd debugging. So I started with Ubuntu in Virtual Box. This was a little bit slow on my Laptop so I searched for a better solution. What is easier than installing Ubuntu from the Windows Microsoft Store? With this app I got full Linux command line support. But how does this work?

The ability to support different subsystems was built into the Windows kernel long time ago. The first Windows NT version did support OS/2 console application for instance. Windows 10 can now run native Linux ELF64 binaries. It does this without emulation and without recompiling Linux code.

The WSL consists of user mode and kernel mode components. In kernel mode there is a driver which translates Linux system calls to the Windows kernel. Sometimes there is a direct mapping, sometimes there is some extra work to do.

In user mode there is the pico process in which system calls are dispatched to this driver. This process is an outcome of the Drawbridge research prototype. A goal of this prototype was to decouple a Windows process from the underlying OS on which it is executed. This is tailor-made for running Linux applications on Windows 10. Although it was not designed for this.

To use WSL you need to active the Windows Feature “Windows-Subsystem for Linux”. This installs the basic functionality. When this is done you can install a distribution from the Microsoft Store.

When I started Ubuntu the first time I saw the error message “Unsupported console settings. In order to use this feature the legacy console must be disabled.“ constantly filling up the console window. The problem was that the legacy console was activated which is obviously incompatible to WSL.

RavenDB, Docker and F#


Here is a little F# application which connects to a RaveDB database, adds an entry and reads them. I used this application to play with RavenDB running inside a Docker container.

open Raven.Client.Documents

type Customer = {
    FirstName: string
    LastName: string
}

[<EntryPoint>]
let main argv =
    printfn "Hello RaveDB!"

    use store = new DocumentStore ()
    store.Urls <-  [|"http://10.0.75.1:8080"|]
    store.Database <- "RavenDB1"
    use store = store.Initialize ()
    
    use session = store.OpenSession ()
    let customer1 = { FirstName = "Guy"; LastName = "Montag" }
    session.Store customer1
    session.SaveChanges ()

    let customers = query {
        for customer in session.Query<Customer>() do
        select customer
    }

    customers |> Seq.iter (printf "%A")

    printfn "Done!"
    0

You can download the full project from my GitHub repository.

https://github.com/chuchu/sandbox/tree/master/ravendb/raven1

From the code you can see that the database runs on 10.0.75.1 which is the IP address of my Docker bridge.

To execute a RavenDB Docker container you need to download the image first. You can do this by executing the command:

docker pull ravendb/ravendb

This will download the latest ubuntu based version. To run the image its best to use the run-ubuntu1604.ps1 powershell script which is provided by the RavenDB project.

ubuntu1604.ps1 -AuthenticationDisabled -PublicServerUrl "http://10.0.75.1:8080"

Disabling authentication is good for testing purposes. So there is no need to deal with certificates. Why it is necessary to provide the PublicServerUrl is something what I don’t really understand completely. But this article explains it a little bit.

https://ayende.com/blog/178819/bug-stories-how-do-i-call-myself

Now you can open your browser, go to http://10.0.75.1:8080 and create the database RavenDB1. When the database is up and running the application can be executed.

dotnet run

When everything works as expected the F# application can be deployed in a container too. Before the image can be created you need to make a release build.

dotnet publish -c release -o app

The docker file is available in the repository. So you just need to type

docker build -t hello-ravendb .

Have a look for the line

Successfully built 388344c214f3

Your ID is surely different, but you need it to run your image.

docker run 388344c214f3

You should see the same output as when the application was executed directly.

Avoid subscribing to events in constructors


While adopting a unit test I found a piece of code which looks pretty much like this one:

public Subscriber(Printer printer, string message)
{
    printer.Print += OnPrint;

    if (message == null)
    {
        throw new ArgumentNullException("message");
    }

    myMessage = message;
}

This is the constructor of a class called Subscriber. In the first statement it subscribes an external event. Afterwards it checks a message parameter and might throw an exception. The following question comes to my mind. What happens to the event when the exception is thrown? Is there some zombie object assigned to the Print multicast delegate? Indeed it is! When you have the following code:

var s = new Subscriber(printer, null);

You will get an exception, but the instance was created somehow. The assignment to the s variable did not happen because of the exception but it is there. Typically the instance would be deleted with the next garbage collector run, but not when someone keeps a reference. In case of the Subscriber the Printer class keeps a reference with its Print event and so it cannot be garbage collected. What makes it even worse is, that the event handler of the zombie instance is called when the Print event is raised.

So be very careful when subscribing to events in constructors. If anything they should appear as last statement.

iTunes audiobooks


Vor längerem habe ich mir ein kleines Powershell Skript gebaut, welches ein mp3 Hörbuch nach m4b konvertiert. Es also iTunes kompatibel macht. Dabei kann man angeben in wie viele m4b Dateien das Hörbuch konvertiert werden soll. Es werden aber nur mehrere mp3s zusammengefasst. Sie werden nicht geschnitten. Alle mp3 Dateien finden sich im m4b als Kapitel wieder.

Das Skript benutzt:
•    lame um die mp3 Dateien zurück ins wave Format zu konvertieren
•    taglib-sharp um die Länge einer mp3 Datei zu ermitteln
•    neroaacenc um die wave Dateien ins aac Format zu konvertieren
•    neroaactag um die aac Dateien zu taggen
•    mp4chaps um die Kapitel marken ins ITunes Format zu konvertieren

Alle Programme müssen in der PATH variablen sein. Die taglib-sharp.dll wird von C:\Tools\taglib-sharp.dll geladen das kann man aber leicht ändern. Am besten man legt alles unter C:\Tools und fügt dieses Verzeichnis zu dem PATH hinzu.

Das Skript muss dann in dem Verzeichnis aufgerufen werden, in dem die mp3s liegen. Das Skript durchsucht dann rekursiv alle Unterordner. Aufgerufen wird es wie folgt:

mp32audiobook.ps1  -author “Stephen King” -title “Es” – bookCount 10 – cover .\cover.jpeg

Bei bookCount handelt es sich um die Anzahl an m4b Dateien die erzeugt werden sollen. Dabei handelt es sich allerdings eher um eine Empfehlung an das Skript. Wie gesagt, es werden keine mp3 geschnitten. Somit können auch nicht mehr m4b Dateien erzeugt werden als es mp3s gibt.

Zu finden gibt es das Skript bei GitHub.

File System Redirector


Wenn man aus einem 32 Bit Prozess heraus versucht eine Anwendung zu starten die unter C:\Windows\System32 liegt, wird der Pfad direkt zu C:\Windows\SysWOW64 übersetzt. Der Grund dafür ist, dass unter System32 die 64 Bit files liegen und unter SysWOW64 die 32 Bit Versionen. Für die Umleitung ist der File System Redirector verantwortlich. Das ist zwar alles ganz praktische, aber was wenn man aus dem 32 Bit Prozess wirklich die 64 Bit Anwendung starten möchte?

Dieses Problem hatte ich zum Beispiel mit Visual Studio. Ich wollte ein Powershell Script per external Tool einbinden, welches alle Prozesse beendet, die eine bestimmte DLL geladen haben. Die 32 Bit Powershell kann aber scheinbar nicht die Module eines 64 Bit Prozesses auflisten. Deshalb muss man die 64 Bit Version verwenden. Also habe ich im VS C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe als external Tool angegeben. Seltsamerweise hat dann mein Script aber nicht funktioniert. Nach etwas Suchen habe ich im process explorer gesehen,  dass immer die 32 Bit Powershell gestartet wird. Obwohl ich extra die 64  Bit Version angegeben habe. Stackoverflow brachte mich dann auf den File System Redirector und die Lösung für mein Problem. Man muss %windir%\sysnative als system Pfad verwenden. Dieser wird dann auch nicht geändert. Es muss also %windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe als external Tool angegeben werden.

dodned Usergroup Franken


Gestern war ich zum ersten Mal auf einem Treffen der dotned Usergroup Franken und habe auch zum ersten Mal an einem coding dojo teilgenommen.

Es war wirklich sehr Witzig das FizzBuzz „Problem“ mittels TDD und mit pair programming zu lösen. Trotz der einfachen Natur der Aufgabenstellung ist es interessant wie viele Diskussionen es  über die Implementierung der Lösung gab. Das zeigt eines ganz deutlich: Kein Problem ist so einfach, als dass man es mit VHIT (vom Hirn ins Terminal) lösen sollte.

Beim nächsten Treffen bin ich auch wieder dabei 😉

Literate Programming


Im allseits bekannte Clean Code Buch wird ein Programm aus dem Literate Programming Artikel von Donald E. Knuth verwendet. Weil der Code so schön kryptisch war, habe ich mir diesen Text mal ganz Text durchgelesen. Zumindest teilweise. Es geht darin um eine Art Sprache die in TeX und in Pascal übersetzt werden kann. Also man bekommt am Ende ein ausführbares Programm und eine schöne Dokumentation. Ja, für was TeX nicht so alles gut ist. Dieses System hat er WEB genannt. Gleich auf der ersten Seite erklärt er auch wie er zu diesem Name kam:

“I chose the name WEB partly because it was one of the few three-letter words of English that hadn’t already been applied to computers.”

Ist schon witzig. Der Artikel ist von 1983. Heute denkt man bei diesen drei Buchstaben an was anderes. Wie er das wohl heute nennen würde?

CDRip mit MinGW unter Windows7 übersetzen


So! Endlich! Ich weiß gar nicht wie viele Stunden ich jetzt damit verbracht die CDRip Bibliothek zu übersetzen. Das man dazu MinGW braucht, war ja noch aus der Readme ersichtlich. Aber make lieferte immer ganz seltsame Fehlermeldungen. Es sah so aus als würden die Variablen im Makefile einfach nur teilweise ersetzt. Nach ewiger rumprobiererei und einem make Auffrischungskurs, kam ich mal darauf das Makefile in der MinGW Konsole mit cat auszugeben. Dort konnte man nun sehen, dass viele Sachen in einer Zeile standen, die überhaupt nicht in eine Zeile gehören. Seltsam. Im Notepad++ sah das ganz anders aus. Dann viel mein Blick auf die Statusleiste im Notepad. Dort stand Macintosh! Nach einer kurzen Recherche im Internet wusste ich, dass die line endings im Macintosh Format anders sind als unter Windows oder Linux. Auch fand ich eine Tool was zwischen den verschieden Formaten hin und her konvertieren kann. Nach dem alle Textdateien konvertiert waren, ließ sich die DLL ohne weiteres übersetzen. Puh, das war Nervenaufreibend!