linux

Bad passwords for SSH

From Christian Seifert’s “Analyzing malicious SSH login attempts” (SecurityFocus: 11 September 2006):

First, we analyzed the login names that were used on the login attempts. During the sample period, there were 2741 unique account names ranging from common first names, system account names, and common accounts to short alphabetical strings captured by the system logger. Of those, the 15 account names used most often are shown in Table 1. This table shows accounts that usually exist on a system (root, mysql), accounts that are likely to exist on a system (guest, test), as well as common first names (paul). Then Figure 1 shows the distribution of valid and invalid account names that were used.

Account Name Number of login attempts
root 1049
admin 97
test 87
guest 40
mysql 31
info 30
oracle 27
postgres 27
testing 27
webmaster 27
paul 25
web 24
user 23
tester 22
pgsql 21

Table 1. Top 15 account names among 2741 attempts.

Next, we looked at the passwords used in the login attempts. The attackers tried a range of passwords with most of the account names. In total during our analysis, they attempted to access 2741 different accounts and used 3649 different passwords. Not all passwords were used with all accounts. The passwords ranged from account names, account names with number sequences, number sequences, and keyboard sequences (like ‘qwerty’). There were a few more complex passwords used with seemingly random letter and number sequences or common substitution passwords (like r00t or c@t@lin).

Table 2 shows the top 15 passwords used in malicious login attempts.

Password Number of login attempts
123456 331
Password 106
Admin 47
Test 46
111111 36
12345 34
administrator 28
Linux 23
Root 22
test123 22
1234 21
123 20
Mysql 19
Apache 18
Master 18

Table 2. Top 15 passwords attempted.

My reply to those “You sent a virus to me!” emails

On Saturday 17 April 2004, I received the following email from someone I didn’t know:

> Hello,
>
> I am not sure who you are but our security detected a Netsky virus in an
> email that you sent. Whether a personal message or a spam, please make
> attention to the fact that you are spreading viruses and have your systems
> checked. Also, when a virus is detected the message does not get through so
> we have no idea who you are or the nature of your message.

My reply

I really wouldn’t bother sending these messages out, or you will find yourself with a full-time job.

Virtually every modern virus spoofs the sender of the email address of the sender. In other words, the virus scans the infected computer for email addresses, and then picks one for the TO field and one for the FROM field. Someone that has both of our email addresses on their computer is infected, and the virus chose your email address for TO and my email address for FROM. That is the extent of it. Unfortunately, we have no way to knowing who really is infected, so emailing the person who appears to have sent the email is a complete waste of your time.

Finally, I could not be infected, as I do not use Windows. I use Linux, which is impervious to the glut of viruses and worms that infect Microsoft’s poorly-coded operating system.

Cultural differences between Unix and Windows

From Joel Spolsky’s “Biculturalism” (Joel on Software: 14 December 2003):

What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers.

This is, of course, a major simplification, but really, that’s the big difference: are we programming for programmers or end users? Everything else is commentary. …

Let’s look at a small example. The Unix programming culture holds in high esteem programs which can be called from the command line, which take arguments that control every aspect of their behavior, and the output of which can be captured as regularly-formatted, machine readable plain text. Such programs are valued because they can easily be incorporated into other programs or larger software systems by programmers. To take one miniscule example, there is a core value in the Unix culture, which Raymond calls “Silence is Golden,” that a program that has done exactly what you told it to do successfully should provide no output whatsoever. It doesn’t matter if you’ve just typed a 300 character command line to create a file system, or built and installed a complicated piece of software, or sent a manned rocket to the moon. If it succeeds, the accepted thing to do is simply output nothing. The user will infer from the next command prompt that everything must be OK.

This is an important value in Unix culture because you’re programming for other programmers. As Raymond puts it, “Programs that babble don’t tend to play well with other programs.” By contrast, in the Windows culture, you’re programming for Aunt Marge, and Aunt Marge might be justified in observing that a program that produces no output because it succeeded cannot be distinguished from a program that produced no output because it failed badly or a program that produced no output because it misinterpreted your request.

Similarly, the Unix culture appreciates programs that stay textual. They don’t like GUIs much, except as lipstick painted cleanly on top of textual programs, and they don’t like binary file formats. This is because a textual interface is easier to program against than, say, a GUI interface, which is almost impossible to program against unless some other provisions are made, like a built-in scripting language. Here again, we see that the Unix culture values creating code that is useful to other programmers, something which is rarely a goal in Windows programming.

Which is not to say that all Unix programs are designed solely for programmers. Far from it. But the culture values things that are useful to programmers, and this explains a thing or two about a thing or two. …

The Unix cultural value of visible source code makes it an easier environment to develop for. Any Windows developer will tell you about the time they spent four days tracking down a bug because, say, they thought that the memory size returned by LocalSize would be the same as the memory size they originally requested with LocalAlloc, or some similar bug they could have fixed in ten minutes if they could see the source code of the library. …

When Unix was created and when it formed its cultural values, there were no end users. Computers were expensive, CPU time was expensive, and learning about computers meant learning how to program. It’s no wonder that the culture which emerged valued things which are useful to other programmers. By contrast, Windows was created with one goal only: to sell as many copies as conceivable at a profit. …

For example, Unix has a value of separating policy from mechanism which, historically, came from the designers of X. This directly led to a schism in user interfaces; nobody has ever quite been able to agree on all the details of how the desktop UI should work, and they think this is OK, because their culture values this diversity, but for Aunt Marge it is very much not OK to have to use a different UI to cut and paste in one program than she uses in another.

My new book – Linux Phrasebook – is out!

I’m really proud to announce that my 3rd book is now out & available for purchase: Linux Phrasebook. My first book – Don’t Click on the Blue E!: Switching to Firefox – was for general readers (really!) who wanted to learn how to move to and use the fantastic Firefox web browser. I included a lot of great information for more technical users as well, but the focus was your average Joe. My second book – Hacking Knoppix – was for the more advanced user who wanted to take advantage of Knoppix, a version of Linux that runs entirely off of a CD. You don’t need to be super-technical to use and enjoy Hacking Knoppix, but the more technical you are, the more you’ll enjoy the book. Linux Phrasebook is all about the Linux command line, and it’s perfect for both Linux newbies and experienced users. In fact, when I was asked to write the book, I responded, “Write it? I can’t wait to buy it!”

The idea behind Linux Phrasebook is to give practical examples of Linux commands and their myriad options, with examples for everything. Too often a Linux user will look up a command in order to discover how it works, and while the command and its many options will be detailed, something vitally important will be left out: examples. That’s where Linux Phrasebook comes in. I cover a huge number of different commands and their options, and for every single one, I give an example of usage and results that makes it clear how to use it.

Here’s the table of contents; in parentheses I’ve included some (just some) of the commands I cover in each chapter:

  1. Things to Know About Your Command Line
  2. The Basics (ls, cd, mkdir, cp, mv, rm)
  3. Learning About Commands (man, info, whereis, apropos)
  4. Building Blocks (;, &&, |, >, >>)
  5. Viewing Files (cat, less, head, tail)
  6. Printing and Managing Print Jobs (lpr, lpq, lprm)
  7. Ownerships and Permissions (chgrp, chown, chmod)
  8. Archiving and Compression (zip, gzip, bzip2, tar)
  9. Finding Stuff: Easy (grep, locate)
  10. The find command (find)
  11. Your Shell (history, alias, set)
  12. Monitoring System Resources (ps, lsof, free, df, du)
  13. Installing software (rpm, dkpg, apt-get, yum)
  14. Connectivity (ping, traceroute, route, ifconfig, iwconfig)
  15. Working on the Network (ssh, sftp, scp, rsync, wget)
  16. Windows Networking (nmblookup, smbclient, smbmount)

I’m really proud of the whole book, but the chapter on the super-powerful and useful find command is a standout, along with the material on ssh and its descendants sftp and scp. But really, the whole book is great, and I will definitely be keeping a copy on my desk as a reference. If you want to know more about the Linux command line and how to use it, then I know you’ll enjoy and learn from Linux Phrasebook.

You can read about and buy the book at Amazon (http://www.amazon.com/gp/product/0672328380/) for $10.19. If you have any questions or comments, don’t hesitate to contact me at scott at granneman dot com.

Unix specs vs. Windows specs

From Peter Seebach’s Standards and specs: Not by UNIX alone (IBM developerWorks: 8 March 2006):

In the past 20 years, developers for “the same” desktop platform (“whatever Microsoft ships”) have been told that the API to target is (in this order):

* DOS
* Win16
* OS/2
* Win32
* WinNT
* WinXP
* and most recently .NET.

Of course, that list is from last year, and now the “stable” target that you should be developing for, if you have an eye for the future, is Vista.

It hasn’t been quite as bad in the Macintosh world, where the number of major API changes has been limited: classic single-tasking Mac OS, classic multitasking Mac OS (System 7), Carbon (System 8/9 and preview of OS X), and Cocoa (OS X), but even there, the cost of migration has been significant. At least OS X finally offers a stable UNIX API for the back-end part of programs, allowing developers to ignore the API creep except in GUI code.

By contrast, twenty-year-old UNIX utilities still compile and run. A new desktop computing API will come and everyone will have to rewrite for it, but mountains will erode away before read() and write() stop working. This is the reason that all the hassle of formal UNIX standards has had so little effect on practical UNIX software development; the core API is simple, clean, and well-designed, and there is no need to change it significantly.

… UNIX users have been switching hardware platforms since the 1970s; it’s no big deal. …

Just as there are many varieties of UNIX, there are many UNIX standards:

* Probably the oldest standard that people still refer to is AT&T’s 1985 System V Interface Definition (SVID). This standard shows up, for instance, in man pages describing the standards compliance of functions that have been in the C library “forever.”
* Meanwhile, X/Open (now the Open Group) was developing “portability guides” with names like XPG2, XPG3, and so on. XPG1 was actually released in 1995. The XPG guides are largely subsumed into newer specs, but once again, are still referred to sometimes in documentation.
* The IEEE’s POSIX standard showed up in 1990 with updates in 1992 and 1993 and a second edition in 1996. It’s still a viable standard, although it has suffered from poor accessibility. POSIX specs have names like 1003.x; for instance, 1003.1 and 1003.2, which refer to different parts of the standard, or 1003.1-1988 and 1003.1-1990, which refer to two versions of the standard.
* The fairly ominous sounding “Spec 1170” (also known as “UNIX 98” or “Single Unix Specification”) is probably the most complete specification; it is produced by the Open Group, and is effectively a descendant of the XPG series. In practice, this is “the” UNIX standard these days, although it’s a little large; this has had an impact on conformance testing.
* The Linux Standards Base is not strictly a UNIX standard, but it’s a standardization effort relevant to a very large number of developers working with code designed to run “on UNIX.” …

You can look at OS specifications in two very different ways: one is from the point of view of a developer trying to port an application, and the other is from the point of view of the user trying to interact with the system.

UNIX conveniently blurs this distinction. The primary user interface is also one of the primary development environments; therefore, UNIX specifications often cover not only the C language API, but also the shell environment and many of the core utilities shell programmers rely on. …

From the perspective of a developer who’s seen many Unix-like systems, Linux is probably mostly sort of similar to System V. The heavy focus on GNU utilities gives a sort of surreal combination of Berkeley and System V features, but if you have to guess whether Linux does something the Berkeley way or the System V way, go with System V. This is especially true of system startup; nearly all Linux systems use the System V /etc/inittab and /etc/rc.d structure, or something very close to it. …

Ubuntu Hacks available now

The Ubuntu distribution simplifies Linux by providing a sensible collection of applications, an easy-to-use package manager, and lots of fine-tuning, which make it possibly the best Linux for desktops and laptops. Readers of both Linux Journal and TUX Magazine confirmed this by voting Ubuntu as the best Linux distribution in each publication’s 2005 Readers Choice Awards. None of that simplification, however, makes Ubuntu any less fun if you’re a hacker or a power user.

Like all books in the Hacks series, Ubuntu Hacks includes 100 quick tips and tricks for all users of all technical levels. Beginners will appreciate the installation advice and tips on getting the most out of the free applications packaged with Ubuntu, while intermediate and advanced readers will learn the ins-and-outs of power management, wireless roaming, 3D video acceleration, server configuration, and much more.

I contributed 10 of the 100 hacks in this book, including information on the following topics:

  • Encrypt Your Email and Important Files
  • Surf the Web Anonymously
  • Keep Windows Malware off Your System
  • Mount Removable Devices with Persistent Names
  • Mount Remote Directories Securely and Easily
  • Make Videos of Your Tech-Support Questions

I’ve been using K/Ubuntu for over a year (heck, it’s only two years old!), and it’s the best distro I’ve ever used. I was really excited to contribute my 10 hacks to Ubuntu Hacks, as this is defintely a book any advanced Linux user would love.

Buy Ubuntu Hacks from Amazon!

Unix vs Windows: NYC vs Celebration

From David HM Spector’s Unfinished Business Part 2: Closing the Circle (LinuxDevCenter: 7 July 2003):

The UNIX world is the result of natural evolution, not the outgrowth of a planned community. UNIX is a lot like New York City: dynamic, always reinventing itself, adapting to new needs and realities. Windows is a lot like Celebration, USA: static, a set piece of predictability, slow to provide new services and very resistant to change or difference of view or opinion.

Virtual-machine based rootkits

From Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, & Jacob R. Lorch’s “SubVirt: Implementing malware with virtual machines
” [PDF] (: ):

We evaluate a new type of malicious software that gains qualitatively more control over a system. This new type of malware, which we call a virtual-machine based rootkit (VMBR), installs a virtual-machine monitor underneath an existing operating system and hoists the original operating system into a virtual machine. Virtual-machine based rootkits are hard to detect and remove because their state cannot be accessed by software running in the target system. Further, VMBRs support general-purpose malicious services by allowing such services to run in a separate operating system that is protected from the target system. We evaluate this new threat by implementing two proof-of-concept VMBRs. We use our proof-of-concept VMBRs to subvert Windows XP and Linux target systems, and we implement four example malicious services using the VMBR platform. Last, we use what we learn from our proof-of-concept VMBRs to explore ways to defend against this new threat. We discuss possible ways to detect and prevent VMBRs, and we implement a defense strategy suitable for protecting systems against this threat. …

A major goal of malware writers is control, by which we mean the ability of an attacker to monitor, intercept, and modify the state and actions of other software on the system. Controlling the system allows malware to remain invisible by lying to or disabling intrusion detection software.

Control of a system is determined by which side occupies the lower layer in the system. Lower layers can control upper layers because lower layers implement the abstractions upon which upper layers depend. For example, an operating system has complete control over an application’s view of memory because the operating system mediates access to physical memory through the abstraction of per-process address spaces. Thus, the side that controls the lower layer in the system has a fundamental advantage in the arms race between attackers and defenders. If the defender’s security service occupies a lower layer than the malware, then that security service should be able to detect, contain, and remove the malware. Conversely, if the malware occupies a lower layer than the security service, then the malware should be able to evade the security service and manipulate its execution.

Because of the greater control afforded by lower layers in the system, both security services and rootkits have evolved by migrating to these layers. Early rootkits simply replaced user-level programs, such as ps, with trojan horse programs that lied about which processes were running. These user-level rootkits were detected easily by user-level intrusion detection systems such as TripWire [29], and so rootkits moved into the operating system kernel. Kernel-level rootkits such as FU [16] hide malicious processes by modifying kernel data structures [12]. In response, intrusion detectors also moved to the kernel to check the integrity of the kernel’s data structures [11, 38]. Recently, researchers have sought to hide the memory footprint of malware from kernel-level detectors by modifying page protections and intercepting page faults [43]. To combat such techniques, future detectors may reset page protections and examine the code of the page-fault handler. …

Our project, which is called SubVirt, shows how attackers can use virtual-machine technology to address the limitations of current malware and rootkits. We show how attackers can install a virtual-machine monitor (VMM) underneath an existing operating system and use that VMM to host arbitrary malicious software. The resulting malware, which we call a virtual- machine based rootkit (VMBR), exercises qualitatively more control than current malware, supports general-purpose functionality, yet can completely hide all its state and activity from intrusion detection systems running in the target operating system and applications. …

A virtual-machine monitor is a powerful platform for malware. A VMBR moves the targeted system into a virtual machine then runs malware in the VMM or in a second virtual machine. The targeted system sees little to no difference in its memory space, disk space, or execution (depending on how completely the machine is virtualized). The VMM also isolates the malware’s state and events completely from those of the target system, so software in the target system cannot see or modify the malicious software. At the same time, the VMM can see all state and events in the target system, such as keystrokes, network packets, disk state, and memory state. A VMBR can observe and modify these states and events—without its own actions being observed—because it completely controls the virtual hardware presented to the operating system and applications. Finally, a VMBR provides a convenient platform for developing malicious services. A malicious service can benefit from all the conveniences of running in a separate, general-purpose operating system while remaining invisible to all intrusion detection software running in the targeted system. In addition, a malicious service can use virtual-machine introspection to understand the events and states taking place in the targeted system. …

In the overall structure of a VMBR, a VMBR runs beneath the existing (target) operating system and its applications (Figure 2). To accomplish this, a VMBR must insert itself beneath the target operating system and run the target OS as a guest. To insert itself beneath an existing system, a VMBR must manipulate the system boot sequence to ensure that the VMBR loads before the target operating system and applications. After the VMBR loads, it boots the target OS using the VMM. As a result, the target OS runs normally, but the VMBR sits silently beneath it.

To install a VMBR on a computer, an attacker must first gain access to the system with sufficient privileges to modify the system boot sequence. There are numerous ways an attacker can attain this privilege level. For example, an attacker could exploit a remote vulnerability, fool a user into installing malicious software, bribe an OEM or vendor, or corrupt a bootable CD-ROM or DVD image present on a peer-to-peer network. On many systems, an attacker who attains root or Administrator privileges can manipulate the system boot sequence. On other systems, an attacker must execute code in kernel mode to manipulate the boot sequence. We assume the attacker can run arbitrary code on the target system with root or Administrator privileges and can install kernel modules if needed. …

VMBRs use a separate attack OS to deploy malware that is invisible from the perspective of the target OS but is still easy to implement. None of the states or events of the attack OS are visible from within the target OS, so any code running within an attack OS is effectively invisible. The ability to run invisible malicious services in an attack OS gives intruders the freedom to use user-mode code with less fear of detection.

We classify malicious services into three categories: those that need not interact with the target system at all, those that observe information about the target system, and those that intentionally perturb the execution of the target system. In the remainder of this section, we discuss how VMBRs support each class of service.

The first class of malicious service does not communicate with the target system. Examples of such services are spam relays, distributed denial-of-service zombies, and phishing web servers. A VMBR supports these services by allowing them to run in the attack OS. This provides the convenience of user-mode execution without exposing the malicious service to the target OS.

The second class of malicious service observes data or events from the target system. VMBRs enable stealthy logging of hardware-level data (e.g., keystrokes, network packets) by modifying the VMM’s device emulation software. This modification does not affect the virtual devices presented to the target OS. For example, a VMBR can log all network packets by modifying the VMM’s emulated network card. These modifications are invisible to the target OS because the interface to the network card does not change, but the VMBR can still record all network packets. …

The third class of malicious service deliberately modifies the execution of the target system. For example, a malicious service could modify network communication, delete e-mail messages, or change the execution of a target application. A VMBR can customize the VMM’s device emulation layer to modify hardware-level data. A VMBR can also modify data or execution within the target through virtual-machine introspection.

Using our proof-of-concept VMBRs, we developed four malicious services that represent a range of services a writer of malicious software may want to deploy. We implemented a phishing web server, a keystroke logger, a service that scans the target file system looking for sensitive files, and a defense countermeasure that defeats a current virtual-machine detector. …

To avoid being removed, a VMBR must protect its state by maintaining control of the system. As long as the VMBR controls the system, it can thwart any attempt by the target to modify the VMBR’s state. The VMBR’s state is protected because the target system has access only to the virtual disk, not the physical disk.

The only time the VMBR loses control of the system is in the period of time after the system powers up until the VMBR starts. Any code that runs in this period can access the VMBR’s state directly. The first code that runs in this period is the system BIOS. The system BIOS initializes devices and chooses which medium to boot from. In a typical scenario, the BIOS will boot the VMBR, after which the VMBR regains control of the system. However, if the BIOS boots a program on an alternative medium, that program can access the VMBR’s state.

Because VMBRs lose control when the system is powered off, they may try to minimize the number of times full system power-off occurs. The events that typically cause power cycles are reboots and shutdowns. VMBRs handle reboots by restarting the virtual hardware rather than resetting the underlying physical hardware. By restarting the virtual hardware, VMBRs provide the illusion of resetting the underlying physical hardware without relinquishing control. Any alternative bootable medium used after a target reboot will run under the control of the VMBR.

In addition to handling target reboots, VMBRs can also emulate system shutdowns such that the system appears to shutdown, but the VMBR remains running on the system. We use ACPI sleep states [3] to emulate system shutdowns and to avoid system power-downs. ACPI sleep states are used to switch hardware into a low-power mode. This low-power mode includes spinning down hard disks, turning off fans, and placing the monitor into a power-saving mode. All of these actions make the computer appear to be powered off. Power is still applied to RAM, so the system can come out of ACPI sleep quickly with all memory state intact. When the user presses the power button to “power-up” the system, the computer comes out of the low-power sleep state and resumes the software that initiated the sleep. Our VMBR leverage this low-power mode to make the system appear to be shutdown; when the user “powers-up” the system by pressing the power button the VMBR resumes. If the user attempts to boot from an alternative medium at this point, it will run under the control of the VMBR. We implemented shutdown emulation for our VMware-based VMBR. …

We first measure the disk space required to install the VMBR. Our Virtual PC-based VMBR image is 106 MB compressed and occupies 251 MB of disk space when uncompressed. Our VMware-based VMBR image is 95 MB compressed and occupies 228 MB of disk space uncompressed. The compressed VMBR images take about 4 minutes to download on a 3 Mb/s cable modem connection and occupy only a small fraction of the total disk space present on modern systems. …

The installation measurements include the time it takes to uncompress the attack image, allocate disk blocks, store the attack files, and modify the system boot sequence. Installation time for the VMware-based VMBR is 24 seconds. Installation for the Virtual PC-based VMBR takes longer (262 seconds) because the hardware used for this test is much slower and has less memory. In addition, when installing a VMBR underneath Windows XP, we swap the contents of the disk blocks used to store the VMBR with those in the beginning of the Windows XP disk partition, and these extra disk reads/writes further lengthen the installation time.

We next measure boot time, which we define as the amount of time it takes for an OS to boot and reach an initial login prompt. Booting a target Linux system without a VMBR takes 53 seconds. After installing the VMware-based VMBR, booting the target system takes 74 seconds after a virtual reboot and 96 seconds after a virtual shutdown. It takes longer after a virtual shutdown than after a virtual reboot because the VMM must re-initialize the physical hardware after coming out of ACPI sleep. In the uncommon case that power is removed from the physical system, the host OS and VMM must boot before loading the target Linux OS. The VMware-based VMBR takes 52 seconds to boot the host OS and load the VMM and another 93 seconds to boot the target Linux OS. We speculate that it takes longer to boot the target OS after full system power-down than after a virtual reboot because some performance optimizations within the VMware VMM take time to warm up.

Booting a target Windows XP system without a VMBR takes 23 seconds. After installing the Virtual PC-based VMBR, booting the target system takes 54 seconds after a virtual reboot. If power is removed from the physical system, the Virtual PC-based VMBR takes 45 seconds to boot the host OS and load the VMM and another 56 seconds to boot the target Windows XP OS. …

Despite using specialized guest drivers, our current proof-of-concept VMBRs use virtualized video cards which may not export the same functionality as the underlying physical video card. Thus, some high-end video applications, like 3D games or video editing applications, may experience degraded performance.

The physical memory allocated to the VMM and attack OS is a small percentage of the total memory on the system (roughly 3%) and thus has little performance impact on a target OS running above the VMBR. …

In this section, we explore techniques that can be used to detect the presence of a VMBR. VMBRs are fundamentally more difficult to detect than traditional malware because they virtualize the state seen by the target system and because an ideal VMBR modifies no state inside the target system. Nonetheless, a VMBR does leave signs of its presence that a determined intrusion detection system can observe. We classify the techniques that be used to detect a VMBR by whether the detection system is running below the VMBR, or whether the detection system is running above the VMBR (i.e., within the target system). …

There are various ways to gain control below the VMBR. One way to gain control below the VMBR is to use secure hardware. Intel’s LaGrande [25], AMD’s platform for trustworthy computing [2], and Copilot [36] all propose hardware that can be used to develop and deploy low-layer security software that would run beneath a VMBR.

Another way to gain control below the VMBR is to boot from a safe medium such as a CD-ROM, USB drive or network boot server. This boot code can run on the system before the VMBR loads and can view the VMBR’s quiescent disk state. …

A third way to gain control below the VMBR is to use a secure VMM [17]. Like alternative bootable media, secure VMMs gain control of the system before the operating system boots. Running a secure VMM does not by itself stop a VMBR, as a VMBR can still insert itself between the VMM and the operating system. However, a secure VMM does retain control over the system as it runs and could easily add a check to stop a VMBR from modifying the boot sequence above the secure VMM. …

There are several reasons why traditional techniques (e.g., having the target system scan memory or disk) may not be able to detect a VMBR. First, the target system is confined to its virtual machine. Since the VMBR stores its state outside that virtual machine, the target system will see no suspicious changes in its own state. Second, even if the target system did see something amiss, the VMBR could tamper with the execution of the detector and force it to report incorrect results. …

A fundamental perturbation of the VMBR is that it uses machine resources such as CPU time, memory and disk space, and possibly network bandwidth. A VMBR adds CPU overhead to trap and emulate privileged instructions, as well as to run any malicious services. …

In addition to CPU overhead, a VMBR uses memory and disk space. A detector can detect this overhead by running a program that requires the entire machine’s memory or disk space. A VMBR can hide its space overhead in several ways. It can hide its memory overhead by mapping target pages with the same contents to the same physical page [47] or by paging some data to disk. While this extra paging activity may increase the running time of the program, the memory overhead of VMware was too small to measure in our tests. A VMBR can hide its disk overhead by compressing a portion of the disk, sharing disk blocks with the same contents, or pretending that the disk space it uses have bad sectors. …

Another type of perturbation is caused by the variety of I/O devices on the computer. Recall that a VMM typically virtualizes all I/O devices. However, virtualizing the I/O device without changing the target’s view of the device requires one to understand the interface and semantics of each device. This is a formidable task, given the wide variety of I/O devices present on today’s computing platforms. Instead, current VMMs emulate a small number of virtual devices (often with customized interfaces to improve performance [1, 34]). The target OS must then use the drivers for the emulated virtual devices. …

A final source of perturbations are caused by the imperfect virtualization of today’s x86 processors. Sensitive, non-privileged instructions like sidt leak information about the VMM yet do not trap to the VMM [31, 37]. …

We expect future enhancements to the x86 platform to reduce these perturbations. Upcoming virtualization support from Intel [45] and AMD [7] will enable more efficient virtualization. These enhancements eliminate sensitive, non-privileged instructions so they cannot be used from the CPU’s user-mode to detect the presence of a VMM. These enhancements may also accelerate transitions to and from the VMM, and this may reduce the need to run specialized guest drivers. …

However, VMBRs have a number of disadvantages compared to traditional forms of malware. When compared to traditional forms of malware, VMBRs tend to have more state, be more difficult to install, require a reboot before they can run, and have more of an impact on the overall system. Although VMBRs do offer greater control over the compromised system, the cost of this higher level of control may not be justified for all malicious applications.

Ballmer says Windows is more secure than Linux

From Steven J. Vaughan-Nichols’s “Longhorn ‘Wave’ Rolling In” (eWeek: 20 October 2004):

The questions led into a discussion of Linux, with Bittmann observing that there’s a market perception that Linux is more secure.

“It’s just not true,” Ballmer responded. “We’re more secure than the other guys. There are more vulnerabilities in Linux; it takes longer for Linux developers to fix security problems. It’s a good decision to go with Windows.”

Google on the Google File System (& Linux)

From Sanjay Ghemawat, Howard Gobioff, & Shun-Tak Leung’s “The Google File System“:

We have designed and implemented the Google File Sys- tem, a scalable distributed file system for large distributed data-intensive applications. It provides fault tolerance while running on inexpensive commodity hardware, and it delivers high aggregate performance to a large number of clients. …

The file system has successfully met our storage needs. It is widely deployed within Google as the storage platform for the generation and processing of data used by our ser- vice as well as research and development efforts that require large data sets. The largest cluster to date provides hun- dreds of terabytes of storage across thousands of disks on over a thousand machines, and it is concurrently accessed by hundreds of clients. …

We have seen problems caused by application bugs, operating system bugs, human errors, and the failures of disks, memory, connectors, networking, and power sup- plies. Therefore, constant monitoring, error detection, fault tolerance, and automatic recovery must be integral to the system.

Second, files are huge by traditional standards. Multi-GB files are common. Each file typically contains many applica- tion objects such as web documents. When we are regularly working with fast growing data sets of many TBs comprising billions of objects, it is unwieldy to manage billions of ap- proximately KB-sized files even when the file system could support it. As a result, design assumptions and parameters such as I/O operation and blocksizes have to be revisited.

Third, most files are mutated by appending new data rather than overwriting existing data. Random writes within a file are practically non-existent. Once written, the files are only read, and often only sequentially. …

Multiple GFS clusters are currently deployed for different purposes. The largest ones have over 1000 storage nodes, over 300 TB of diskstorage, and are heavily accessed by hundreds of clients on distinct machines on a continuous basis. …

Despite occasional problems, the availability of Linux code has helped us time and again to explore and understand system behavior. When appropriate, we improve the kernel and share the changes with the open source community.

Unpatched Linux, 3 months; unpatched Windows, 20 minutes

From Bruce Schneier’s “Linux Security“:

I’m a big fan of the Honeynet Project … Basically, they wire computers up with sensors, put them on the Internet, and watch hackers attack them.

They just released a report about the security of Linux:

Recent data from our honeynet sensor grid reveals that the average life expectancy to compromise for an unpatched Linux system has increased from 72 hours to 3 months. …

This is much greater than that of Windows systems, which have average life expectancies on the order of a few minutes.

… That’s the real story: the hackers aren’t bothering with Linux. Two years ago, a vulnerable Linux system would be hacked in less than three days; now it takes three months.

Why? My guess is a combination of two reasons. One, Linux is that much more secure than Windows. Two, the bad guys are focusing on Windows — more bang for the buck.

My new book – Hacking Knoppix – available now

Knoppix is one of the great innovations in open source software in the last few years. Everyone that sees it wants to use it, since it is that rarest of software tools: the true Swiss Army Knife, capable of use by unsophisticated, experienced, and wizardly users, able to perform any of several hundred (if not thousand) tasks in an efficient and powerful way. Best of all, it’s super easy to employ, ultra-portable, and platform- and hardware-agnostic.

Knoppix camps on your system without canceling out your regular installation or messing with your files. And it’s really fun to play with. Hacking Knoppix provides all kinds of ways to customize Knoppix for your particular needs, plus the scoop on various Knoppix distros. Learn to build a Knoppix first-aid kit for repairing cranky Windows and rescuing precious data, or create your own Live CD. In short, Hacking Knoppix will transform your ordinary powerless Knoppix-curious individual into a fearsome Knoppix ninja, able to right wrongs, recover data, and vanquish the forces of ignorance and Windows usage once and for all.

Our approach in Hacking Knoppix is smart, detailed, and fun. We know our stuff, and we want our readers to understand and enjoy all the outrageously cool things that Knoppix makes possible. If a topic is kind of hard to understand, we’ll explain it so that lesser experienced readers get it and more experienced readers still learn something new; if a point needs in-depth explanation, we’ll give it in an interesting fashion; and if it needs a splash of humor to relieve the tedium, we’ll slip in something humorous, like a banana peel in front of Bill Gates.

  • Knoppix is an innovative Linux distribution that does not require installation, making it ideal to use for a rescue system, demonstration purposes, or many other applications
  • Shows hack-hungry fans how to fully customize Knoppix and Knoppix-based distributions
  • Readers will learn to create two different Knoppix-based live CDs, one for children and one for Windows recovery
  • Teaches readers to use Knoppix to work from a strange computer, rescue a Windows computer that won’t boot, repair and recover data from other machines, and more
  • Includes Knoppix Light 4.0 on a ready-to-use, bootable live CD

Read sample excerpts, including Unraveling the Knoppix Toolkit Maze (1.7 MB PDF), the complete Table of Contents (135 kb PDF) & the Index (254 kb PDF).

Buy Hacking Knoppix from Amazon!

Tim O’Reilly’s definition of open source

From Tim O’Reilly’s “Lessons from open source software development”, Communications of the ACM 41 (4): 33-7:

Open source is a term that has recently gained currency as a way to describe the tradition of open standards, shared source code, and collaborative development behind software such as the Linux and FreeBSD operating systems, the Apache Web server, the Perl, Tcl, and Python languages, and much of the Internet infrastructure, including Bind (The Berkley Internet Name Daemon servers that run the Domain Name System), the Sendmail mail server, and many other programs. … [But] open source … means more than the source code is available. The source must be available for redistribution without restriction and without charge, and the license must permit the creation of modifications and derivative works, and must allow those derivatives to be redistributed under the same terms as the original work.

Nothin’ like nerdy Microsoft humor

In January 2002, I was running for the position of Vice President of the St. Louis Unix Users Group. On the SLUUG listserv, someone proposed that those running for office come clean on any ethical lapses. Here’s what I wrote:

Fine … I’ll go first and admit my ethical lapses.

I used to use Windows. A lot. All the time. It was really hard to stop. I mean, it came free with my computer. The guy at the store said, “Hey, try it. It’s free. Everyone else is doing it. You’ll feel good.” So I did. I gave in. I was weak. And then it got really hard to just say no. I kept giving more and more money to Microsoft, and Microsoft had me in its claws. I’d come to it every couple of days: “Hey, Microsoft, got anything else for me?” I sold things to buy more Microsoft products. I withdrew from my family, my friends, other people. Finally, one day I hit bottom … I looked around, and saw little multi-colored flags everywhere on my computer. I knew I was powerless. And that’s when I knew things had to change. I came to a LUG meeting, and I stood up, and I said, “Hi. My name is Scott, and I’m a Windows user.” Everyone was really nice … a lot of them had been in the same situation I was. Since then, the group has helped me gain the strength to get the Microsoft monkey off my back, and now I’m happier and more fulfilled than I ever was. Thank you, St. Louis Unix Users Group!

Crack Windows passwords in seconds

This is an oldie but still a goodie – or a baddie, if you use or depend on Windows. Back in 2003, researchers released tools that enable the cracking of Windows passwords in an average of 13.6 seconds. Not bad, not bad at all. CNET has a nice writeup titled Cracking Windows passwords in seconds, which explains that the best way to guard against the attack is to create passwords that use more than just alphanumeric items. In other words, read my SecurityFocus column from May 2004, Pass the Chocolate, which contains this advice: “… you should use a mix of at least three of these four things: small letters, capital letters, numbers, and symbols. If you can use all four, great, but at least use three of them.”

If you want to download and test the security of your Windows passwords, you can grab the software at Ophcrack. You can get source, as well as binaries for Windows and Linux. There’s even an online demo of the software, in which you can paste a hash of the password you’d like to crack and get back the actual password. Nice!

BSD vs. Linux

As a Linux user, I don’t have a lot of daily experience using BSD. Oh sure, I use it on a couple of servers that I rent, but I certainly have never used it on the desktop. And while I certainly understand the concepts, history, and ideas behind Linux very well (although there’s always more to learn), I don’t really know that much about BSD. So it was a delight to read BSD vs. Linux.

“It’s been my impression that the BSD communit{y,ies}, in general, understand Linux far better than the Linux communit{y,ies} understand BSD. I have a few theories on why that is, but that’s not really relevant. I think a lot of Linux people get turned off BSD because they don’t really understand how and why it’s put together. Thus, this rant; as a BSD person, I want to try to explain how BSD works in a way that Linux people can absorb.”

In particular, I thought the contrast between the non-unified nature of Linux and the unified nature of BSD was pretty darn fascinating. As the author points out, this is not to criticize Linux – it’s just the way it is. It’s not a value judgment. Here’s the author on BSD:

“By contrast, BSD has always had a centralized development model. There’s always been an entity that’s “in charge” of the system. BSD doesn’t use GNU ls or GNU libc, it uses BSD’s ls and BSD’s libc, which are direct descendents of the ls and libc that where in the CSRG-distributed BSD releases. They’ve never been developed or packaged independently. You can’t go ‘download BSD libc’ somewhere, because in the BSD world, libc by itself is meaningless. ls by itself is meaningless. The kernel by itself is meaningless. The system as a whole is one piece, not a bunch of little pieces.”

11 pages of really interesting, well-explained analysis. If you’re a Linux user, go read it. You’ll learn about the other great open source OS.