[[Tools#Forensics_Live_CDs | Forensic Linux Live CD distributions]] are widely used during computer forensic investigations. Currently, many vendors of such Live CD distributions spread false claims that their distributions "do not touch anything", "write protect everything" and so on. Community-developed distributions are not exception here, unfortunately. Finally, it turns out that many forensic Linux Live CD distributions are not tested properly and there are no suitable test cases developed.

+

[[Live CD|Forensic Live CDs]] are widely used during computer forensic investigations. Currently, many vendors of such Live CD distributions spread false claims that their distributions "do not touch anything", "write protect everything" and so on. Unfortunately, community-developed distributions are no exception here. Finally, it turns out that many Linux-based forensic Live CDs are not tested properly and there are no suitable test cases published.

== Another side of the problem ==

== Another side of the problem ==

−

Another side of the problem of insufficient testing of forensic Live CD distributions is that many users do not know what happens "under the hood" of such distributions and cannot adequately test them.

+

Another side of the problem of insufficient testing of forensic Live CDs is that many users do not know what happens "under the hood" of the provided operating system and cannot adequately test them.

=== Example ===

=== Example ===

Line 15:

Line 15:

== Problems ==

== Problems ==

−

Here is a list of common problems of forensic Linux Live CD distributions that can be used by developers and users for testing purposes. Each problem is followed by an up to date list of distributions affected.

+

Each problem is followed by an up to date list of distributions affected.

=== Journaling file system updates ===

=== Journaling file system updates ===

Line 66:

Line 66:

| SPADA

| SPADA

| 4

| 4

+

|-

+

| DEFT Linux

+

| 7

|}

|}

Line 74:

Line 77:

[[Image:Grml.png|thumb|right|[[grml]] mounted root file system from the [[hard drive]]]]

[[Image:Grml.png|thumb|right|[[grml]] mounted root file system from the [[hard drive]]]]

−

Currently, Casper may select fake root file system image on evidentiary media (e.g. [[HDD]]), because there are no authenticity checks performed (except optional UUID check for a possible live file system), and this fake root file system image may be used to execute malicious code during the boot with root privileges. Knoppix-based forensic Live CD distributions are vulnerable to the same attack.

+

Currently, Casper may select fake root file system image on evidentiary media (e.g. [[Hard Drive|HDD]]), because there are no authenticity checks performed (except optional UUID check for a possible live file system), and this fake root file system image may be used to execute malicious code during the boot with root privileges. Knoppix-based forensic Live CD distributions are vulnerable to the same attack.

−

List of Ubuntu-based and Debian-based distributions that allow root file system spoofing:

+

List of Ubuntu-based distributions that allow root file system spoofing:

{| class="wikitable" border="1"

{| class="wikitable" border="1"

Line 96:

Line 99:

|-

|-

| Raptor

| Raptor

−

| 20091026

+

| 2.0

−

|-

+

−

| grml ''(uses Casper fork - live-initramfs)''

+

−

| 2009.10

+

|-

|-

| BackTrack

| BackTrack

Line 117:

Line 117:

=== Swap space activation ===

=== Swap space activation ===

−

=== Incorrect mount policy ===

+

''Feel free to add information about swap space activation during the boot in some distributions''

−

==== HAL ====

+

=== Incorrect mount policy ===

==== rebuildfstab and scanpartitions scripts ====

==== rebuildfstab and scanpartitions scripts ====

+

+

Several forensic Linux Live CD distributions (Helix3 2009R1, Helix3 Pro 2009R3, old versions of CAINE, old versions of grml) use rebuildfstab and scanpartition scripts to create entries for attached devices in ''/etc/fstab''. Some versions of these scripts use wrong wildcards while searching for available block devices (''/dev/?d?'' instead of ''/dev/?d*''), this results in missing several "exotic" devices (like /dev/sdad, /dev/sdad1, etc) and in data writes when mounting them (because fstab lacks of read-only mount options for these devices).

=== Incorrect write-blocking approach ===

=== Incorrect write-blocking approach ===

+

+

Some forensic Linux Live CD distributions rely on [[hdparm]] and [[blockdev]] programs to mount file systems in read-only mode (by setting the underlying block device to read-only mode). Unfortunately, setting the block device to read-only mode does not guarantee that [http://archives.free.net.ph/message/20090721.105120.99250e3f.en.html no write commands will be passed to the drive].

The problem

Forensic Live CDs are widely used during computer forensic investigations. Currently, many vendors of such Live CD distributions spread false claims that their distributions "do not touch anything", "write protect everything" and so on. Unfortunately, community-developed distributions are no exception here. Finally, it turns out that many Linux-based forensic Live CDs are not tested properly and there are no suitable test cases published.

Another side of the problem

Another side of the problem of insufficient testing of forensic Live CDs is that many users do not know what happens "under the hood" of the provided operating system and cannot adequately test them.

Example

For example, Forensic Cop Journal (Volume 1(3), Oct 2009) describes a test case when an Ext3 file system was mounted using "-o ro" mount flag as a way to write protect the data. The article says that all tests were successful (i.e. no data modification was found after unmounting the file system), but it is known that damaged (i.e not properly unmounted) Ext3 file systems cannot be write protected using only "-o ro" mount flags (write access will be enabled during file system recovery).

And the question is: will many users test damaged Ext3 file system (together with testing the clean one) when validating their favourite forensic Live CD distribution? My answer is "no", because many users are unaware of such traits.

Problems

Each problem is followed by an up to date list of distributions affected.

Journaling file system updates

When mounting (and unmounting) several journaling file systems with only "-o ro" mount flag a different number of data writes may occur. Here is a list of such file systems:

File system

When data writes happen

Notes

Ext3

File system requires journal recovery

To disable recovery: use "noload" flag, or use "ro,loop" flags, or use "ext2" file system type

Ext4

File system requires journal recovery

To disable recovery: use "noload" flag, or use "ro,loop" flags, or use "ext2" file system type

ReiserFS

File system has unfinished transactions

"nolog" flag does not work (see man mount). To disable journal updates: use "ro,loop" flags

XFS

Always (when unmounting)

"norecovery" flag does not help (fixed in recent 2.6 kernels). To disable data writes: use "ro,loop" flags.

Incorrect mount flags can be used to mount file systems on evidentiary media during the boot process or during the file system preview process. As described above, this may result in data writes to evidentiary media. For example, several Ubuntu-based forensic Live CD distributions mount and recover damaged Ext3/4 file systems on fixed media (e.g. hard drives) during execution of initrd scripts (these scripts mount every supported file system type on every supported media type using only "-o ro" flag in order to find a root file system image).

Root file system spoofing

Most Ubuntu-based forensic Live CD distributions use Casper (a set of scripts used to complete initialization process during early stage of boot). Casper is responsible for searching for a root file system (typically, an image of live environment) on all supported devices (because a bootloader does not pass any information about device used for booting to the kernel), mounting it and executing /sbin/init program on a mounted root file system that will continue the boot process. Unfortunately, Casper was not designed to meet computer forensics requirements and is responsible for damaged Ext3/4 file systems recovery during the boot (see above) and root file system spoofing.

Currently, Casper may select fake root file system image on evidentiary media (e.g. HDD), because there are no authenticity checks performed (except optional UUID check for a possible live file system), and this fake root file system image may be used to execute malicious code during the boot with root privileges. Knoppix-based forensic Live CD distributions are vulnerable to the same attack.

List of Ubuntu-based distributions that allow root file system spoofing:

Swap space activation

Feel free to add information about swap space activation during the boot in some distributions

Incorrect mount policy

rebuildfstab and scanpartitions scripts

Several forensic Linux Live CD distributions (Helix3 2009R1, Helix3 Pro 2009R3, old versions of CAINE, old versions of grml) use rebuildfstab and scanpartition scripts to create entries for attached devices in /etc/fstab. Some versions of these scripts use wrong wildcards while searching for available block devices (/dev/?d? instead of /dev/?d*), this results in missing several "exotic" devices (like /dev/sdad, /dev/sdad1, etc) and in data writes when mounting them (because fstab lacks of read-only mount options for these devices).

Incorrect write-blocking approach

Some forensic Linux Live CD distributions rely on hdparm and blockdev programs to mount file systems in read-only mode (by setting the underlying block device to read-only mode). Unfortunately, setting the block device to read-only mode does not guarantee that no write commands will be passed to the drive.