Showing posts with label /dev/null. Show all posts
Showing posts with label /dev/null. Show all posts

Wednesday, April 29, 2009

/dev/null And /dev/zero On Linux And Unix: What's The Difference?

Hey there,

Today we're going to take a look at a relatively simple concept that's relatively simple to get confused; especially if you're relatively new to Unix or Linux. Your experience may vary. It's all relative (who didn't see that one coming from around the corner and down the block? ;)

The concept we'll be looking at is the dead-zone on Linux or Unix. Most people refer to it as /dev/null or the "bit bucket." And, of course, this prompts the question of "why is that so interesting?" I suppose, in and of itself, it's not. Don't get too excited ;)

Where it gets interesting is when we introduce the /dev/zero file (technically, like /dev/null, a pseudo-file). Most folks, at least initially, consider /dev/null and /dev/zero to be virtually equivalent. And, even though the names make that conclusion seem self-evident, the truth is actually quite the opposite. The two files differ quite drastically, although not in every aspect.

1. Writing to /dev/null and /dev/zero: You can write to both /dev/null and /dev/zero in exactly the same way. For instance, if you want to dump off output from a command, either one will do. That is to say that:

host # echo hi >/dev/null

and

host # echo hi >/dev/zero

will both send your output to "never never land." Executing either of the above commands will satisfy your requirements if you just want to "dump" output to "nowhere." They should both be character (or raw) devices, have identical major device numbers and only differ at the minor device number level. These numbers will differ from OS to OS, but the basic definitions above should hold relatively true.

2. Reading from /dev/null and /dev/zero: This is where the difference between the two files becomes apparent. The most significant difference is exposed in the "reading" since this action highlights the major way in which the two differ.

/dev/null is, essentially, a black hole. Writes to it (as noted above), basically go down the drain. They go nowhere, stay there and you can't get them back. When you "read" from /dev/null, the same rule holds true. /dev/null is virtually "nothing," and all reads from it produce no output whatsoever. For instance, this output from Solaris' truss (you can get the same from Linux's "strace" and similar utilities) shows what happens when /dev/null is read from (e.g. "cat /dev/null") - below, what you'd see at the command line, followed by a snippet of truss output from the almost-immediate end of the command's execution:

host # cat /dev/null
host #
host # truss cat /dev/null
...
open64("/dev/null", O_RDONLY) = 3
fstat64(3, 0xFFBFF950) = 0
read(3, 0x000222A0, 8192) = 0
llseek(3, 0, SEEK_CUR) = 0
close(3) = 0
close(1) = 0
_exit(0)
host #


literally, the device file is opened, read from (which produces nothing) and is closed, since an EOF is sent immediately after opening.

/dev/zero, on the other hand is not the black hole that it appears to be when "writing to it." When you "read" from /dev/zero, you get a much different result than when you read from /dev/null. This is most specifically because /dev/zero returns zero's until the cows come home (or you stop reading from it ;) and "does not" return an EOF like /dev/null. It actually returns the ASCII null character (0x00) ad infinitum (or "ad naseum" depending upon your stomach for this sort of thing ;)

Below, we'll take a look at what you'd see at the command line, followed by a snippet of truss output from this command's execution:

host # cat /dev/zero
^C
host #
<-- note that we had to type ctl-C (send an interrupt signal) to the return from "cat /dev/zero" to get it to return to the shell prompt
host # truss cat /dev/zero
...
open64("/dev/zero", O_RDONLY) = 3
fstat64(3, 0xFFBFF950) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192


...and on it goes until we (or another process) interrupts it.

And that, pretty basically, is the difference between the two files. It should be noted, however, that there are two things you can do with /dev/zero that you can't do with /dev/null (one practical and one just downright malicious if you know what you're doing ;) and one very useful thing you can use /dev/null for on a regular basis.

1. /dev/null can be easily used to create a zero byte file. This comes in handy when you want to create a placeholder file, etc:

host # cat /dev/null >FILE
host # ls -l FILE
host # ls -l FILE
-rw-r--r-- 1 user123 unixgrp 0 Apr 28 11:37 FILE


of course, the same results can be achieved (in most shells) in a more efficient manner. The underlying mechanism is the same, but the typing's a bit speedier (and you're actually redirecting STDOUT, but we'll leave that distinction to the academics ;)

host # >FILE
host # ls -l FILE
-rw-r--r-- 1 user123 unixgrp 0 Apr 28 11:37 FILE


2. With /dev/zero, the good thing you can do is to create a zeroed out file on which you can, later, create a filesystem. Using a simple command like "dd" you can set /dev/zero as your input file ("if") and your block device (or regular file) as the output file ("of") and then make a filesystem on it. This is a very quick way to setup additional file system space:

host # dd if=/dev/zero of=mynewfile <-- the block size - "bs" - and count - "count" - arguments will differ depending upon your fs and what your particular needs are
host # mkfs ARGS mynewfile <-- Again, this part (creating the new filesystem) can have many variables. The most relevant command line component, in this instance, would be the name of the zeroed out file we create with "dd."

3. With /dev/zero, the "bad" thing you can do (or can do by mistake, if you're not careful or aren't aware of /dev/zero's behaviour) is related to the "good" thing. Just like you can create a zeroed out file system, you can also completely fill a partition with ASCII 0x00 characters and, possibly, cause your system to crash or go into a frenzy as it loses disk resources, like so (of course, you should not have the permission to do this as a regular user):

host # cd /var
host # cat /dev/zero >FILE
cat: output error (0/8192 characters written)
No space left on device
host # df -k /var
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s4 4130238 4120138 0 100% /var


so, in about 100 seconds, you can cripple /var (4 GB of space on this host). That makes it difficult to do simple things, like copying over a relatively small file onto the partition you just filled up (not to mention the other adverse effects filling up /var can have on most Linux and Unix OS's):

host # ls -l /bin/ls
-r-xr-xr-x 1 root bin 27380 Jun 11 2008 /bin/ls
host # cp /bin/ls /var/ls
cp: /var/ls: write: No space left on device


Of course, this practice is not recommended. Just a small example to illustrate why you should take care when playing around with /dev/zero!

Here's hoping today's post was of some help to you or, at the very least, provided an interesting diversion for a few moments ;)

Cheers,

, Mike




Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!



Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Sunday, November 16, 2008

Fake Unix and Linux Advisory - The /dev/null Vulnerability

Hey again,

Here's a little something from 2003 (Remember way back then, when the future looked bright and almost anything seemed possible? ...me neither ;)

This is a humorous little fake CERT-like advisory concerning the implementation of /dev/null on all Unix and Linux operating systems and the disastrous effects of ignoring the problem. The bit I've put here was pulled from Ian's Humor Pages, which you might want to check out and find all the other funny stuff on there :)

Hope you enjoy it. I'm going away now to appease the "simple syndication" beast. Is this short enough for you, oh mighty and vainglorious Google RSS? ;)

Cheers,





From: lsloof@cirt.us (Dr. Lirpa Sloof)
Newsgroups: alt.security,comp.security.unix,comp.os.linux.security
Subject: CIRT Advisory CA-2003-0401: /dev/null Vulnerability
Date: 01 Apr 2003 08:21:28 GMT
Organization: Computer Incident Response Team (CIRT)
Message-ID: <advisory-ca-2003-0401@announce.cirt.us>
NNTP-Posting-Host: nimbus.thunder.net


CIRT Advisory CA-2003-0401 /dev/null Vulnerability
Computer Incident Response Team

Systems Affected

* Windows CE, ME, NT, 2000, XP, 98, 95
* Linux (all distributions)
* BSD-derived Operating Systems
* Solaris
* IRIX
* HP-UX
* Digital/Compaq Tru64 Unix
* AIX
* other Unix-compatible systems and Unix-compatibility libraries

Overview

There is a vulnerability in /dev/null on Unix systems, Unix-compatible
systems and those with Unix or POSIX compatibility libraries (including
Windows) that can be exploited to cause a denial-of-service condition
and could cause hardware damage to some systems in isolated cases.
Though rare, the possibility of hardware damage is the primary reason
why this advisory is being categorized as urgent.

I. Description

A vulnerability has been discovered with the algorithm most commonly
used to implement /dev/null on Unix and Unix-compatible systems which
can be used to cause damage to other software connected to it. In some
cases, this software damage can also trigger hardware damage. These
vulnerabilities can be exploited by a local user already logged into
the system for a denial-of-service. If used in conjunction with
remote exploit attacks, this could allow a remote attacker, worm or
virus to cause hardware damage on some systems. In even more rare
circumstances there are possibilities of bodily injury in bystanders.

II. Impact

The contemporary method of /dev/null drivers is described as the "high
suction algorithm" in comparison with the replacement that vendors have
made available for their systems. If a malicious user uses a program
with low-resistance logic to connect /dev/null back into itself,
the device goes critical and can be used for destructive purposes.
Once the /dev/null device driver enters a critical state, programs with
low-resistance logic will break, be consumed by /dev/null and expose
their standard input to the full force of /dev/null itself. Some examples
which have been verified in labs include the following:
* Programs which are consumed by /dev/null become permanent entry points
to /dev/null afterward.
* If standard input is redirected from any regular file, it will be
"sucked dry" and left empty. File permissions do not prevent loss
of data.
* If standard input is redirected from a directory, all the files and
directories within it will be sucked dry, recusrively removing an
entire directory tree.
* If standard input is redirected from a pipe or named pipe, it will
expose the full force of the critical state /dev/null to the program
on the other end of the pipe. As with direct linkage to /dev/null,
if the program contains logic too weak to resist the suction, it
will be consumed and permanently become a portal to /dev/null itself.
* If standard input is redirected from a keyboard device, the keyboard
will implode, crushing the keys. This has the possibility to cause
minor lacerations if anyone is typing on the keyboard at the time of the
implosion.
* If standard input is redirected from a mouse device, it will pop like
a weasel in a microwave oven.
* If standard input is redirected from a CRT monitor driver, the device
is unaffected because it already contains a vaccuum.
* If standard input is redirected from a disk driver, the drive will
be erased and the lubrication removed from the bearings. In lab tests
the disk platter has exited the drive at high speed in a random
direction. Note that if this occurs in a data center environment,
the platter is likely to embed itself in other computer hardware.
There is a risk of injury if a disk platter or other shrapnel from
the self-destructing disk drive should hit any person.
* If standard input is redirected from a network device, the results
have been very unpredictable. The effects appear to be mainly
confined within the local area network (LAN). In all cases, all
packets are sucked off the network.
* An ethernet hub is too weak to resist the suction and becomes a
vaccuum port for /dev/null.
* All ethernet switches and broadband network interfaces are immune
to the effects.
* In one home where a user-modified digital video recorder (DVR) device
was connected to the network, the existing recordings were erased.
But the device was running Linux so its own /dev/null created enough
suction that the pressure differential caused no further damage.
* In another home where a refrigerator was connected to the network,
all the food inside became freeze-dried.
* The most violent reaction was found where a home automation system
was connected to the network. The vaccuum came in contact with the
central air vents and sucked the air out of the house. Everyone
got out safely. But an infestation of termites in the house was
entirely suffocated.

III. Solution

Note that many of the mitigation steps recommended below may have
significant impact on your everyday home or office operations. Use
appropriate caution but also ensure that any changes made based on the
following recommendations will not unacceptably affect your ongoing use
of your computer and occupancy of your building unless you're certain
that a great danger exists in your circumstances.

Apply a patch from your vendor

Appendix A contains information provided by vendors for this advisory.
Please consult this appendix to determine if you need to contact
your vendor directly.

Appendix A. - Vendor Information

This appendix contains information provided by vendors for this
advisory.

Microsoft

The same patch as the fix for the March 17 buffer overflow in the
Windows Core DLL also fixes the high-suction algorithm. Note that
Windows systems are particularly vulnerable to the high-suction
algorithm because all the programs on Windows have weak logic and
are unable to resist the suction. Also, Microsoft has said that
there will be no patch for NT4 because they are unable to build a
new copy of the OS from source code. So NT4 not only sucks, but
it also blows.

Red Hat

Upgrade to kernel kernel-2.4.18-27.7.x (for RedHat Linux 7.x),
kernel-2.4.18-27.8.0 (for RedHat Linux 8.0) or later.

RedHat Linux 9.0 is not vulnerable.

SCO (Caldera)

Upgrade to OpenLinux 3.1.1, UnixWare 7.1.1, OpenUnix 8.0.0
or later.

Debian GNU/Linux

Upgrade to kernel kernel-image-2.4.18* or later for your system.

Mandrake Linux

Upgrade to kernel-2.4.19.32mdk-1-1mdk.* (for Mandrake Linux 9.0,
Corporate Server 2.1) or later.

Mandrake Linux 9.1 is not vulnerable.

SuSE Linux

Upgrade to kernel-2.4.19-20030324 updates (for SuSE Linux 8.1),
kernel-2.4.18-20030324 (for SuSE Linux 7.1-8.0) or later.

SuSE Linux 8.2 is not vulnerable.

Slackware Linux

For Slackware Linux, contact your vendor.

FreeBSD

Upgrade to FreeBSD 5.0 or later.

NetBSD

Upgrade to NetBSD-1.6.1 or later.

OpenBSD

Upgrade to OpenBSD 3.3 or later.

Solaris

Apply patch 114356-01 (Solaris 9), patch 114356-01 (Solaris 8)
or later.

IRIX

Apply update 20030201-01-P.

HP

Apply patch SSRT2322_2341_2384_2412_2439 (HP/Compaq Tru64 Unix).
For HP-UX, contact your vendor.

AIX

For AIX, contact your vendor.





, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.