The scariest type of all, hardware vulnerabilities. Security guru and creator of OpenBSD Theo de Raadt recently announced he had found some fairly serious bugs in the hardware architecture of Intel Core 2 Duo processors.

He goes as far as saying avoid buying a C2D processor until these problems are fixed.

A prominent software developer with a reputation for making waves in coding circles is doing it again – this time warning that Intel’s celebrated Core 2 Duo is vulnerable to security attacks that target known bugs in the processor.

Discussion forums on Slashdot and elsewhere were ablaze with comments responding to the claims made by Theo de Raadt, who is the founder of OpenBSD. Intel strongly discounted the report, saying engineers have thoroughly scanned the processor for vulnerabilities.

In it he warns that errata contained in the Intel processor is susceptible to security exploits that put users and enterprises at serious risk of being compromised. The exposure can exist even in cases where Intel has issued a fix, de Raadt said, because patches in the microcode frequently don’t get installed on systems purchased from smaller vendors or that run less popular operating systems.

“At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year),” de Raadt concluded in his post to an OpenBSD discussion group.

The main problem being, these kind of issues cannot be fixed on a software level they need some re-engineering of the actual chips themselves and due to the nature of hardware vulnerabilities it means they can be exploited on any OS.

Many of the bugs lead to potentially dangerous buffer overflow in which write-protected or non-execute bits for a page table entry are ignored. Others involve floating point instruction non-coherencies or memory corruptions. Intel is aware of the security implications, but has yet to disclose them, he said in an interview.

Intel engineers and some outside security researchers disagree with de Raadt’s conclusion, but the implications of them being correct are serious. Thanks to its high performance and plentiful supply, the Core 2 Duo is seemingly everywhere – in Macs, phone switches and PCs running a wide variety of operating systems.

What’s more, a vulnerability in the processor could be exploited regardless of the OS it runs, and if the flaw resides in the silicon itself, the traditional remedy of pushing out a software patch could be rendered ineffective.

You can find 105 Core 2 errata here as published by Intel:

Core 2 Duo errata [PDF]

And the original e-mail from Theo here:

Intel Core 2

Source: The Register

It’s good to have a variety of Operating Systems in your hacking lab at home, it helps you get familiar with them..as to break things, you have to know how they work first.

So get to know Solaris, they have some pretty neat security related software inside their OS and generally are pretty good when it comes to having a secure architecture with stuff like Trusted Extensions and DTrace.

As they say:

How else to explore and discover for yourself the many innovations and features that Solaris 10 has to offer, than by running Solaris 10 yourself?

So go ahead, grab a copy and start hacking.

To obtain a copy of Solaris 10 Media DVD visit the site below and fill up the form.

Solaris is pwned by a similar vulnerability to one discovered on AIX systems in 1994.

Yes people that’s 13 years ago…and Sun are still vulnerable, as reported by SANS.

The following will give you root on a lot of Solaris systems:

telnet -l "-froot" [hostname]

Cool eh?

The Internet Storm Center is urging system administrators to disable or restrict telnet functionality to contain the zero-day vulnerability, which, according to center, affects only the most recent versions of Solaris and OpenSolaris.

Sun executives talk up secure Solaris at just about every turn. However, some simple tinkering with the OS’s telnet user environment variable can give outsiders free reign with no authentication requirements. No special tools are required to exploit the vulnerability. Sans has long urged against the use of reusable clear-text passwords when administering telnet.

A Sun spokesman says the company has been able to verify the vulnerability and is in the process of testing a fix. He also says that by default telnet is disabled in Solaris 10, and users would have to follow a series of steps to enable it and even more to allow it to administer root privileges. Sun has long recommended Solaris SecureShell as a more secure alternative to telnet.

So disable telnet now, if you haven’t already..Yes I know Sun are still teaching people to use telnet in their classes, which I find kind of sad.

Like someone else said, I doubt any of us would even use telnet on an exposed system…but we have all worked for corporations or seen people that would.

Source: The Register

One way to defend against OS fingerprinting from tools such as nmap, queso, p0f, xprobe etc is to change the metrics that they base their analysis on.

One way to do this with OpenBSD is to use Sealing Wafter.

Goals of Sealing Wafter:
1. To reduce OS detection based on well known fingerprints network stack behavior.
2. To have the ability to load custom rules into the stack.
3. To unload, modify, reload the kernel module with on the fly rules. (great feature at packet parties)
4. To learn how the magic of tcpip stacks work.

What Sealing Wafter currently provides:
1. Hide from Nmap Syn/Xmas/Null scans, as well as the specific fingerprinting packets.
2. Ability to see what your stack is receiving without the need to drop your network device into promisc mode.
3. Complete control over rules that you can load on the fly todeal with specific incoming packets.
4. Initial support for several OS passive detection has been added for SYNs.

Weaknesses in current Sealing Wafter:
1. Full connection scans. e.g. nmap -sT will still find open ports. this is because I have yet to find anything that seperates a real tcp connection vs an nmap full connection. (most likely isn’t one.)
2. Can be very verbose when under heavy load. I have run this on my heaviest web servers, and have not noticed any major overhead.

Download the c code for the LKM here: Sealing Wafter

1. Introduction

This article describes and partly implements a method to delete or re-locate, potentially sensitive and / or incriminating information from your UNIX flavoured machine, after the sad event of your death.

An older version of this article has been published before, yet it has since disappeared from the Internet and the Google cache; hence this re-post.

Initially, the intent of the whole idea of Post-Mortem Data Destruction (PMDD), or Post-Life Data Destruction, was humorous. Thus, this document should be taken lightly.

Incidentally it can be of use to interested people as this article does contain some useful tips / pointers if one decides to build such a system. For some of you that lack common sense: any damage you might cause to your machine after reading this document is entirely your own fault.

Note that this article, obviously, assumes that the machine that the data is on, is under your own control. We will continue to look at various motivations for PMDD, below. Note that this whole theory does not apply when you are using remote storage systems (i.e. virtual drives) as the information is then stored on a remote location and we cannot be sure that the remote system really deletes your data. Their EULA might state that they do but the truly paranoid wouldn’t make the assumption that they really delete it. I sincerely wonder why one would actually ever use such a remote virtual drive — by definition these are un-trusted. But I slightly digress..

2. Motivation

You can have various motivations for wanting your data destroyed after your death:

• You don’t want years of valuable research to fall into the wrong hands,
• You don’t want your girlfriend or room-mates to find your collection of granny pr0n,
• You are paranoid, or just uncomfortable with the idea somebody else will read your stuff after you have died.

Motivations for moving, i.e. sending out certain data upon the event of your death could be:

• You are the maintainer of an important piece of software and you want the other people working on the project to have access to the latest modification you have made,
• You suspect your elimination because of messing around with the wrong people, and want certain data (i.e. copies of emails) to be sent to, for instance, a newspaper.

After you have died, it’s too late: it will be virtually impossible to log in to your machine and delete data. Note that haunting is only reserved to a few (hurt) souls and such a state can not be guaranteed. Fat chance you’re able to sit behind a terminal in the after-life, too.

One could opt for encryption, making it hard for a person to recover the data — but that doesn’t really guarantee anything. In the event of your death, the partitions would be available to anyone that can get their hands on it. If the encrypted partitions are gone, they can never…

Let us continue by making a technical analysis of the problem at hand.

3. Technical Description

You are probably aware of the way that watchdog-chips work; basically they change a byte somewhere in memory regularly, and if that byte hasn’t changed within a set period of time, the machine is possible hanging and needs a reboot.

We can use a similar method to check whether you are still alive: a machine regularly sends you a message (either through email, an SMS or through a carrier pigeon, whichever you prefer) and expects an answer back.

If the machine hasn’t received an answer within a configurable time-lapse, the machine can safely assume that you have died.

This obviously isn’t rocket-science — implementing such a system is pretty straight-forward.

Setting it up is a whole other can of worms: you have to be careful as wrong settings might result in a false-positive. A false-positive might render your machine useless when you come back from your holiday to the Antarctic, where GSM and Internet coverage isn’t really that impressive.

In order for such a ‘system’ to be built, we can divide it up into three, logical, parts:

• Sender: This part sends out the ‘Are You Alive?‘-message (I will refer to this as the an AYA-message further in this document)
• Receiver: This part receives the ‘I Am Alive‘-message (which I will refer to as the IAA-message in the rest of this document),
• Checker: This part checks whether a message has been received within a reasonable amount of time — or not.

  The Checker is the core of the system that makes the actual assumption whether you are still alive (or not) and will initiate the data destruction process.

Below, we will look at each of these three parts with a little more detail.

3.1 Sender

This part must implement the sending of the message. Messages can be sent over numerous transport-media, i.e. email or SMS, so you have to pick the one you prefer. You could also choose sending the AYA-message over more transport-media to be sure that you will receive and answer it in time.

(UNIX users could use ‘crontab’ here to send it out, for instance every day at 21:00 PM. Some checkups need to be built-in though to prevent AYA messages from being sent when the last one hasn’t been responded too, etc. But those are implementation details I will go into later on.)

3.2 Receiver

This part must handle the incoming IAA-message. The location of the Receiver is dependant on the form of transport you have chosen; If you want the AYA-messages to be sent over email, the IAA-message will come in via email.

(UNIX users could use ‘procmail’ here in order to inspect the incoming message, and act upon it.)

3.3 Checker

This part checks regularly whether a AYA message has been sent, and if an IAA message has been received.

If the IAA isn’t received within a reasonable (configurable) amount of time the machine must assume you have died and optionally start emailing some data out before finally destroying it. We will go into the ‘Destruction Process’ later on.

UNIX users could write a simple script for this that retrieves and manipulates the state-information somewhere on the file-system.

All the above mentioned parts should have some redundancy built in and should properly react in error situations. It would be a pain to find out that a message could not be sent because of your ISP being down. In that situation you have never received, thus replied, the AYA message, and your machine will think you are dead…

If you don’t watch out, your data will be deleted and you might as well kill yourself.

4. Death Detection Caveats

Below I will go into various things that you need to keep in mind when implementing a Death Detection system.

4.1 State-Information

The Sender, the Receiver and the Checker all need to be fully aware of eachother: the Sender needs to know if a previous AYA has been answered. We do not want AYA’s sent out when the previous AYA hasn’t been answered yet as doing so might cause a flood of AYA’s that you have to answer to in time, to prevent your machine from destroying itself.

Either through some form of Inter Process Communication, be it in memory through the UNIX IPC system, or simply on disk by using a couple of files.The latter would be a more wise thing to do as it will retain your data in the event of a power outage.

The state-information should be accessible and writable for all the other parts of the system, obviously.

4.2 Configuration and Control

Sending Out The `Are You Alive’-messages
You have to keep a few things in mind setting the times the AYA message must be sent.

If you want your machine to detect your death as soon as possible you have to send out the AYAs every 5 minutes. But do you really want to reply to the email or SMS message every day? I don’t think so. And sending it out, say, every month creates another problem: you might forget all about it just before you go to a place without SMS or email access. Worse case scenario might be that you come back and find out your machine thought you were already dead.

Going On a Holiday?
If you go away on a holiday or know you have no access to email of SMS for some time, you sometimes cannot answer to the messages. Or I can imagine other situation when you don’t want to go through the hassle of replying to the incoming AYA messages, for a short while.

It should be possible to disable the system if you know you cannot respond to AYA messages.

If you want, you could build some extra stuff into the Receiver to handle specific commands. For instance, sending a message like this could disable the system for 14 days.

To: dd-at-domain.com
Subject: STFU 14D


Additionally you could insert a password to prevent abuse.

Implementing certain commands of course requires some changes in all the parts: the Receiver must set some flag in the state-information indicating the Sender and the Checker to do nothing until the flag is unset.

Incidentally, when the Receiver receives a ‘Command Message’ it should assume that the last sent AYA, if still pending, has been responded to. (It is a logic assumption to make that you are still alive if the machine receives a Command Message from you.)

Broken Phone?
Imagine the scenario where you have just received the AYA message — but your phone broke. Or your battery just went dead.

Not nice if you really need to send a message to your computer and the only allowed phone is the one with your Caller-ID.

Just make sure you can control the system from an ‘alien’ phone. Password protected, of course.

Sending Out Your Private Data
This functionality requires some configuration; if you want data to be sent out, the machine needs to know what data and which email-address to send it to. Of course you could also use secure copy (scp) as a way to get the data out.

As an illustration I include a sample configuration-file which should be parsed by the process handling the sending:

# Directory / Target email-address
/home/my_home/development/cracking_tools/ partner_in_crime-at-gmail.com
/home/my_home/911_conspiracy_evidence/ breakingnews-at-bbc.co.uk

After succesfully sending out the information, depending on ones level of paranoia, you could optionally destruct the local copy of this information.

5. Data Destruction Caveats

The only proper way of deleting sensitive data is by Drive-Slagging [too bad the images don't work on that link anymore].

Data destruction is virtually impossible to do if you’re not spending your after-life on Earth as a poltergeist. (See my other pending document which will be out as soon as I got some relevant hands-on experience.)

Be aware that, even after a format, the electromagnetic surface still contains traces of the data previously stored. Forensic experts could theoretically reconstruct the data. It would be harder for these experts if you have written random garbage over your old file-system a couple of times. (Some people say 33 times should be enough, others say 10, while other say “Given enough money and time, all data can be recovered.”.)

In order for us to be able to write over the partition we are possibly currently running on, we have created ourselves a little problem, especially if we want to overwrite parts of the disk a few times. After the first pass, the command you executed (and the libraries it depended on) are gone, so it isn’t guaranteed it comes to the 2nd pass (and you know what they say about assumptions).

An possible solution for this could be to install the Data Destructor on a different, non-mounted, partition.

This partition should be bootable and contain enough programs to perform the destructive disk access operations.

When the Data Destruction should take place, the current LILO of GRUB configuration should be altered to automatically boot into this special partition which will start the destructive task, and reboot making it active.

After rebooting and deleting and overwriting the data (optionally with multiple passes), the machine should shut down.

What finally is left is your special partition (which doesn’t really matter) and some partitions with random garbage on it.

If you want to impress your room-mates you could make this special partition, when booted, display the following message, or similar:

I am dead. You have no reason to look at my computer. Sod off!

Too bad you’re not alive to see the expression on their faces.

Digg This Story

Here’s a series of well written IBM Linux tutorials to help you learn Linux fundamentals and prepare for system administrator certification. The LPI prep tutorials help you prepare for the topics in LPI exam 201 and the topics in LPI exam 202.

You can find more about the certification at the Linux Professional Institute.

I’ve been meaning to take LPI 201 for quite sometime actually, it looks like a pretty solid foundation to Linux and I know most of it allready, so I should be able to do it without too much problem.

You can find the material at IBM:

Linux Professional Institute Exam Prep

The eight tutorials below help you prepare for the eight topics in LPI exam 201. Exam 201 is the first of two LPI intermediate-level system administrator exams. Both exam 201 and exam 202 are required for intermediate-level certification, or LPIC-2.

You do have to sign up, or just use Bugmenot, the bugmenot extension for Firefox is very useful ;)

To any budding hackers, yes it is recommended you have strong Linux skills.