This post explains how to enable UEFI SecureBoot on Debian, using your own trust chain. The
technical part itself is very light, most of the post is explanations and what and why.
What is SecureBoot ?
UEFI SecureBoot is a mechanism to verify a cryptographic signature of UEFI Images before loading
them into the Firmware (the new name for the BIOS1). This provides a way to control which
images are allowed, and also drivers and option ROM used by the Firmware, and to fight bootkits and
malwares based on that. For an example of such dangers, see my past presentations on malicious UEFI
Option ROMs ([FR] at SSTIC, and
[EN] at PacSec).
Roughly, SecureBoot will rely on cryptographic signatures (mainly using SHA-256 and RSA-2048) that
are embedded into files using the
file format. The integrity of the executable is verified by checking the hash, and the authenticity
and the trust by checking the signature, based on X.509 certificates, which has to be trusted by
At a high level, the Firmware has 4 different set of objects (see figures for details):
the Platform Key (PK): this is the main key. This keys, usually belonging to …
Here are the materials for the talk PICON : Control Flow Integrity on LLVM IR,
given during SSTIC 2015. While SSTIC is a
french-speaking conference, I publish here in English because my other posts
also are in English.
Here is the summary, from the website:
Control flow integrity has been a well explored field of software security for
more than a decade.
However, most of the proposed approaches are stalled in a
proof of concept state - when the implementation is publicly available - or have
been designed with a minimal performance overhead as their primary objective,
Currently, none of the proposed approaches can be used to
fully protect real-world programs compiled with most common compilers (e.g. GCC,
In this paper we describe a control flow integrity enforcement
mechanism whose main objective is security. Our approach is based on
compile-time code instrumentation, making the program communicate with its
external execution monitor. The program is terminated by the monitor as soon as
a control flow integrity violation is detected.
Our approach is implemented as
an LLVM plugin and is working on LLVM’s Intermediate Representation.
Compiling a grsec kernel on a
laptop/workstation is a good way to add protection against wide classes
of attacks. However, while the options may be easy to choose on a
server, this may be difficult because a typical desktop needs more
privileges. Here are a few points:
Xorg (wants privileged I/O, unless you use KMS) conflicts with
PAX_NOEXEC and GRKERNSEC_IO
power management: applets to display the battery level want
(non-root) read permission on /sys, this will conflict with
GRKERNSEC_SYSFS_RESTRICT. You can enable SYSFS_DEPRECATED as a workaround.
power management: ACPI is required for a laptop (if you want to be
able to use suspend/resume, control fan speed, etc.)
power management: suspend/restore conflicts with some options
(PAX_MEMORY_UDEREF and PAX_KERNEXEC)
virtualization: PAX_KERNEXEC conflicts with kvm/vmx
If you have other points to add/corrections, just send them to me !
Now, another problem I have is that I must use the proprietary kernel.
Not that I really want to, but it is the only driver with proper support
for my graphics card (GT555M), since the nouveau driver has some
problems here: breaks suspend to ram/disk, sucks battery (I have 2h30 of
autonomy with nouveau, and about 5 with Nvidia …
The Digital Forensics Framework (DFF) is both a digital investigation
tool and a development platform.The framework is used by system
administrators, law enforcement examinors, digital
forensicsresearchers and > students, and security professionals
world-wide. Written in Python and C++,it exclusively uses Open Source technologies.
DFF combines an intuitive user interface with a modular and
DFF is a nice tool, combining Python and C++ (and PyQt) to provide
performances, be easy to extend and provide a nice GUI. It is GPLv2,
thanks to ArxSys.
If you like it, don’t hesitate to contact them on the IRC channel
(#digital-forensic on Freenode).
I have started to work on a Live CD for Open Source tools like Prelude
SIEM, and software like Suricata, Snort, OpenVAS to send alerts. The
goal is to easily test these tools, register new agents, get some alerts
and be able to correlate them etc. I also want to add some visualization
tools, so this CD could maybe become a reference for security alert
detection and report.
First, a few points on applications used:
Debian Live for
building the CD. It’s very easy, it’s based on Debian, and it allows
me to re-use some work I’ve done
is the key point: suricata, snort, syslog etc. will send alerts to
Prelude, which has a database, a correlator, a web interface
Standard useful tools: nmap, scapy, wireshark, p0f, etc.
This first version is based on Debian Lenny and arch x86. Everything is
based on packages (.debs) to make it easier to maintain, upgrade
versions or add patches: most of the time, I just have to rebuild
packages from squeeze or sid.
This month, Joanna Rutkowska implemented the “evil maid” attack
This kind of attack can be done on any OS with disk encryption: when
using whole-disk encryption, you have to infect to bootloader. Linux
which has some nice features (including TKS1 and working encrypted
suspend-to-disk). But how does it play with this attack ?
Sadly, the answer is: pretty bad. LUKS has no protection against this
attack, and even requires a /boot partition in clear. Before looking at
the possible solutions, we’ll play with the /boot partition to see how
simple the attack is.
So, Ipoque has published its deep
inspection engine under a free license (LGPLv3):
OpenDPI This is always good news when a
company decides to release source code to the community, so first of all
thanks to Ipoque for this.
Basically, the project looks quite unprepared for release (only a
Makefile, no configure script - though no-one can be blamed for not
using autotools -), but after looking at the code it seems not so bad:
the code is reasonably clean
it builds fine on x86 or x86_64 platforms
the code is provided with a decent list of identified protocols
the demo uses pcap files
There are a few minor annoyances:
the provided lib is a static lib … building a shared library would
be better !
the build system is pretty awful, rebuilding everything each time,
without using deps, no install system etc.
no docs (looking at the demo file was sufficient to understand most
of the function).
no correct website, forums or whatever. I’m sure it will get better
in the future
This last point was the most annoying to me, so I …