WHITEPAPER | December 31, 2008

Updated PCI Standards: Flexibility, Clarity and Common Sense 2.0

The Payment Card Industry Data Security Standards (PCI DSS) are a set of 12 requirements that merchants and their business partners are expected to follow to ensure the safety of cardholder data. Authored by the PCI Security Standards Council-an independent consortium of representatives from the major credit card brands-the PCI DSS covers data management, information technology, encryption, physical security, legal agreements, and business operations. When these standards were updated from version 1.1 to version 1.2, 30 changes were introduced to the existing requirements.

(more…)

ADVISORIES | October 31, 2008

QNX ker_msg_sendv System Call Integer Overflow

Discovered: 10.30.08. Reported: 10.30.08. Disclosed: 10.31.08. QNX’s ker_msg_sendv() system call contains an integer overflow that could lead to heap corruption and, if correctly exploited, system compromise. If only partially exploited, this could lead to denial-of-service conditions and kernel panic, effectively shutting down the system. (more…)

ADVISORIES | October 21, 2008

DNS TXT Record Parsing Bug in LibSPF2

Reported: 10.20.08. Disclosed: 10.21.08. Researchers discovered a relatively common bug that parses TXT records delivered over DNS-dating back at least to 2002 in Sendmail 8.2.0 and almost certainly much earlier-in LibSPF2. This library retrieves Sender Policy Framework (SPF) records and applies policy according to those records. This implementation flaw allows for relatively flexible memory corruption and should be treated as a path to anonymous remote code execution. (more…)

ADVISORIES | September 30, 2008

Diskimages-helper band-size Vulnerability

Reported to Vendor: 09.30.08. Patch Released: 04.29.09. CVE ID: CVE-2009-0150. A signed-to-unsigned conversion flaw exists in diskimages-helper when it reads the band-size parameter. When the value specified for the band-size key is changed to a negative number, the diskimages-helper process crashes when the user attempts to log in. (more…)

INSIGHTS | September 13, 2008

Reverse-Engineering Custom Logic (Part 1)

Today we are taking you one step deeper into a microchip than we usually go. We look at transistors and the logic functions they compose, which helps us understand custom ASICs now found in some secured processors.

To reverse-engineer the secret functionality of an ASIC, we identify logic blocks, map out the wiring between the blocks, and reconstruct the circuit diagram. Today, we’ll only be looking at the first step: reading logic. And we start with the easiest example of a logic function: the inverter.

To read logic, you first have to find the transistors and decide where Vcc (+) and ground (-) are located. Transistors are easy to spot. They will always look very similar to those two transistors marked in the picture: A rectangle shape with a line in the middle. Vcc is always next to the larger transistors (PMOS) and ground is closer to the smaller ones (NMOS).

Once you identified the transistors, you draw a small circuit diagram that shows how they are connected to each other. In the example, the inputs of the two transistors are connected and so are their outputs on the left side. From this circuit diagram you can read that whatever you assert at the input, the output will be forced to the opposite state — an inverter.

Every gate will follow these basic principles, but vary in the number and constellation of transistors. A 2-NOR gate (Y = !(A|B) ), for instance, is composed of 4 transistors in this setup:

Once you figured out a gate, you can recognize every occurrence of that function on the whole chip because the exact same shape is always used for the same function. Generally, you only need to read a few dozens gates at most to generate a map of functions across whole chip. Get a head start on reading logic and check out the logic gate collection at The Silicon Zoo.

Here is a challenge for you to try (open in GIMP or Photoshop and toggle between the different layers):

It’s about the hardest function found on most chips with a total of 34 transistors, 3 inputs, 2 outputs, and time-variant behavior. The solution will be posted next week.
INSIGHTS |

New Author: Herr Karsten Nohl!

We are proud to announce that those who enjoy reading the blog (which we apologize for the lack of content lately) can soon enjoy reading posts from Karsten Nohl as well.

For those of you who are not familiar with Karsten, he played an important role in the discovery and analysis of the Crypto-1 mathematical algorithm found in Philips (NXP) Mifare RFID devices.

He recently obtained his PhD from University of Virginia in the United States.   He’s well known within the Chaos Computer Club (CCC) in Germany as well.

We too look forward to reading Karsten’s posts.   Feel free to give Karsten a round of applause by posting a quick comment!

Karsten- Congratulations on your PhD!!

ADVISORIES | August 5, 2008

Multiple Vulnerabilities in Apple’s MobileMe Service

Reported: 08.05.08. Patched: 11.06.08 Disclosed: 11.20.08. Apple’s MobileMe (me.com) web service contains several serious security vulnerabilities. The most critical vulnerability combines cross-site request forgery and cross-site scripting, and allows an attacker to access the service without a valid password. (more…)

INSIGHTS | April 3, 2008

Atmel AT91SAM7S Overview

Atmel produces a number of ARM based devices in their portfolio of products. We had one laying around the lab so here we go as usual…

The device was a 48 pin QFP type package. We also purchased a sample of the other members of the family although the initial analysis was done on the AT91SAM7S32 part shown above. All pictures will relate to this specific part even though there is not a signifigant difference between the other members of this line except memory sizes.

After decapsulating the die from inside the QFP, we find a beautifully layed out 210nm 5 metal design! Thats right, 5 metal layers! Strangely enough, we would have thought this was a 220nm 5 metal but apparently Atmel doesn’t have a .22um process so this is matching their .21um.

The core runs at 1.8v and allows 1.65v operation (thus it is their ATC20 process being used). The datasheet on the device can be found here. The 32KB Flash part also contains 8KB of SRAM (that’s a lot of ram!).

Notice on this particular layout, there is CMP filler metal (e.g. dead metal, metal slugs that are not connected to anything floating in SIO2) covering almost the entire die.

The picture above actually has had the top 2 metal layers removed. Metal 5 (M5) being the highest with the CMP filler and some power planes. Metal 4 (M4) had additional power planes and routing wires.

With Metals 1-3 still present, we can get a nice overview of the floorplan now. We can see the Flash, Fuses, and SRAM clearly. The Flash has a solid coating of metal over the entire cell area which has become common from Atmel to prevent UV light attacks we suppose?

We can now label the areas on the original top metal overview photo. There is a small boot-rom loader present on the device as well and is explained in the manual.

These cells were actually on Metal 1 and 2 but there are connections via Metal 3 as well.

There were additional power planes across the lower area of the photo from Metal 4 and 5 that cover those fuses however this isn’t buying them any security if the actual lock bits were buried there. A laser can go right through it all keeping the power-bus in tact with a hole in it.

In summary, this is a very well secured device. Fuses buried in a 5 metal layer design make the Microchip DSPIC’s look like a piece of cake in comparision (They are 350nm 4 metal).

We didn’t test this, but we are sure UV will set this fuses to a bad state if you can get the light to the floating gate since most all Atmel’s behave this way.

Nice job Atmel!

INSIGHTS | February 13, 2008

Atmel CryptoMemory AT88SC153/1608 :: Security Alert

A “backdoor” has been discovered by Flylogic Engineering in the Atmel AT88SC153 and AT88SC1608 CryptoMemory.

Before we get into this more, we want to let you know immediately that this backdoor only involves the AT88SC153/1608 and no other CryptoMemory devices.

The backdoor involves restoring an EEPROM fuse with Ultra-Violet light (UV).  Once the fuse bit has been returned to a ‘1’, all memory contents is permitted to be read or written in the clear (unencrypted).

Normally in order to do so, you need to either authenticate to the device or use a read-once-given “secure code” as explained in the AT88SC153 datasheet and the AT88SC1608 datasheet.

For those of you who are unfamiliar Atmel’s CryptoMemory, they are serial non-volatile memory (EEPROM) that support a clear or secure channel of communications between a host (typically an MCU) and the memory.  What is unique about the CryptoMemory are their capabilities in establishing the secure channel (authenticating to the host, etc).

These device includes:

High-security Memory Including Anti-wiretapping

64-bit Authentication Protocol

Secure Checksum

Configurable Authentication Attempts Counter

These device includes:

  • Multiple Sets of Passwords
  • Specific Passwords for Read and Write
  • Password Attempts Counters
  • Selectable Access Rights by Zone
  • High-security Memory Including Anti-wiretapping
  • 64-bit Authentication Protocol
  • Secure Checksum
  • Configurable Authentication Attempts Counter

Section 5 of the datasheet labled, “Fuses” clearly states, “Once blown, these EEPROM fuses can not be reset.

This statement is absolutely false.  UV light will erase the fuses back to a ‘1’ state.  Care must be used to not expose the main memory to the UV or else it too will erase itself.

We are not going to explain the details of how to use the UV light to reset the fuse.  We have tried to contact Atmel but have not heard anything back from them.

Reading deeper into the datasheet under Table 5-1, Atmel writes, “When the fuses are all “1”s, read and write are allowed in the entire memory.

As strange as it reads, they really do mean even if you have setup security rules in the configuration memory, it doesn’t matter.  The fuses override everything and all memory areas are readable in the clear without the need for authentication or encrypted channel!  The attacker can even see what the “Secure Code” is (it is not given out in the public documentation, nor with samples).  Atmel was even kind enough to leave test pads everywhere so various levels of attackers can learn (entry to expert).

Our proof of concept was tested on samples we acquired through Atmel’s website.  Atmel offers samples to anyone however they do not give out the “Secure code” as mentioned above.
  • The secure code of the AT88SC153 samples was “$D_ $F_ $7_”.
  • The secure code of the AT88SC1608 was “$7_ $5_ $5_”.

We are not going to show you the low nibble of the 3 bytes to make sure we don’t give the code out to anyone.  This is enough proof to whoever else knows this code.  That person(s) can clearly see we know their transport code which appears to be common to all samples (e.g. All die on a wafer contain the same secure code until a customer orders parts at which time that customer receives their own secure code.).  A person reading this cannot guess the secure code in because there are 12 bits to exhaustively search out and you only have 8 tries ;).

Of all the other CryptoMemory products, only the AT88SC153/1608 has this backdoor.  We have successfully analyzed the entire CryptoMemory product line and can say that the backdoor doesn’t exist in any other CryptoMemory part.  None of the CryptoMemory parts are actually as “secure” as they make it seem.  The words, “Smoke n’ Mirrors” comes to mind (It is almost always like that).  In this particular category of CryptoMemory, there are two parts, the AT88SC153 and the larger AT88SC1608.

Thus the questions-
    • Why has Atmel only backdoored this part (NSA for you conspiracists)?
    • Who was the original intended customer supposed to be?
    • Was the original intention of these devices to be used in a product that used some kind of cryptography?

If the above was true, was this device originally intended to be a cryptographic key-vault?

All these questions come to mind because the backdoor makes it so easy to extract the contents of the device they want you to trust.  Some of you may be familiar with the GSM A5/1 algorithm having certain bits of the key set to a fixed value.

Judging by the wording of the documentation, Atmel gives the appearance that CryptoMemory are the perfect choice for holding your most valuable secrets.

Give us your thoughts…

INSIGHTS | February 7, 2008

AT90S8515 – Legacy!

Some people asked for some of those older Atmel parts after seeing the MEGA88 and ATMEGA169 teardowns.

Here’s a quick one on the AT90S8515. It’s still very popular even though it’s been replaced by the MEGA8515. It’s built on a larger process and it’s not planarized (.50um and below are planarized but you may find some .50um non-planarized)

8KB Flash, 512 Byte SRAM, 512 Byte EEPROM with 32 working registers. That’s sooo nice! 4x faster than the typical PIC.

There was a mistake in the above picture too when we highlighted the areas! We forgot to outline the EEPROM area.

The side of the array is touching the ‘8’ in 8KB EEPROM above and it runs vertical along-side the FLASH. So in theory there are two 8 bit FLAH arrays and a single 8 bit EEPROM area all running veritical in the “8KB Flash” highlighted area.

Give us your feedback!