Noah Meyerhans: When You Could Hear Security Scans
Have you ever wondered what a security probe of a computer sounded
like? I d guess probably not, because on the face of it that doesn t
make a whole lot of sense. But there was a time when I could very
clearly discern the sound of a computer being scanned. It sounded
like a small mechanical heart beat: Click-click
click-click click-click
Prior to 2010, I had a computer under my desk with what at the time
were not unheard-of properties: Its storage was based on a stack of
spinning metal platters (a now-antiquated device known as a hard
drive ), and it had a publicly routable IPv4 address with an
unfiltered connection to the Internet. Naturally it ran Linux and an
ssh server. As was common in those days, service logging was handled
by a syslog daemon. The syslog daemon would sort log messages based
on various criteria and record them somewhere. In most simple
environments, somewhere was simply a
file on local storage.
When writing to a local file, syslog daemons can be optionally
configured to use the
fsync()
system call to ensure that writes are flushed to disk. Practically
speaking, what this meant is that a page of disk-backed memory would
be written to the disk as soon as an event occurred that triggered a
log message. Because of potential performance implications, fsync()
was not typically enabled for most log files. However, due to the
more sensitive nature of authentication logs, it was often enabled for
/var/log/auth.log.
In the first decade of the 2000 s, there was a fairly unsophisticated
worm loose on the Internet that would
probe sshd
with some
common username/password combinations.
The worm would pause for a second or so between login attempts, most
likely in an effort to avoid automated security responses. The effect
was that a system being probed by this worm would generate disk write
every second, with a very distinct audible signature from the hard
drive.
I think this situation is a fun demonstration of a side-channel data
leak. It s primitive and doesn t leak very much information, but it
was certainly enough to make some inference about the state of the
system in question. Of course, side-channel leakage issues have been
a concern for ages, but I like this one for its simplicity. It was
something that could be explained and demonstrated easily, even to
somebody with relatively limited understanding of how computers
work , unlike, for instance
measuring electromagnetic emanations from CPU power management units.
For a different take on the sounds of a computing infrastructure,
Peep (The Network Auralizer)
won an award at a USENIX conference long, long ago. I d love to see a
modern deployment of such a system. I m sure you could build
something for your cloud deployment using something like
AWS EventBridge or
Amazon SQS fairly easily.
For more on research into actual real-world side-channel attacks, you
can read
A Survey of Microarchitectural Side-channel Vulnerabilities, Attacks and Defenses in Cryptography
or
A Survey of Electromagnetic Side-Channel Attacks and Discussion on their Case-Progressing Potential for Digital Forensics.
What happened in the 
The annual Debian developer meeting took place in Portland, Oregon, 23 to 31
August 2014. 
Another point release for Etch has been done; now it's the time for the CD
team to roll out new images after the next mirror pulse. The official
announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow
shortly afterwards. FTP master of the day was Joerg Jaspert, who
did his first point release since Woody, as he told us on IRC. We
appreciate your work and you spending your time that shortly before
going to Argentina.
This point release includes the etchnhalf update introducing a new kernel
image (based on 2.6.24) and some driver updates. Additionally the
infamous openssl hole will be fixed for good, even for new installs.
Again I want to present you a list of people who contributed to this
release. It cannot be complete as I got the information out of the