El 16/07/13 16:19, Lew Wolfgang escribió:

Of course one test would be to use fdisk to make sure there's no disk partition label, the presumption being that no label == no filesystem == no malware. You need a filesystem to run a "scan". But is this strictly true?

Yes, at least there can be no malware in the traditional sense.

Maybe the safest course is to zero both the MBR and the label with dd?

Not really, just issue ATA secure erase (unless your concerns goes beyond that.. i.e malware in the drive's firmware, which its existence cannot usually be proven beyond reasonable doubt) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Jul 16, 2013 at 4:19 PM, Lew Wolfgang wrote:

Hi Folks,

I occasionally have to certify that brand new SATA disks don't contain any malware. The concern is of course for MS Windows threats, but policy doesn't care about subtle distinctions, it wants a "scan" to be done on the disks.

Of course one test would be to use fdisk to make sure there's no disk partition label, the presumption being that no label == no filesystem == no malware. You need a filesystem to run a "scan". But is this strictly true?

It is not true. The partition table only occupies a small part of the first sector (ie. the MBR). Some malware such as the very scary code for TDL4 (http://www.securelist.com/en/analysis/204792180/TDL4_Top_Bot) primarily lives in the MBR as I understand it. I'm going from memory, but I believe in 2012 TDL developed an ability to maintain a hidden filesystem at the end of physical disks. For most large drives in windows systems, the last X GBs is never written to. Not during formatting, not during install, and not during day to day use. That means that filesystem that grows down from the end of the disk like a stack does can used those X GB anyway it wants and never be interfered with by the person who thinks he owns the computer. Thus malware absolutely exists that maintains filesystems not documented in the MBR.

Could the "raw" device contain a filesystem that Windows would see?

For example, instead of doing mkfs /dev/sda1, do mkfs /dev/sda. We can then "mount /dev/sda" in Linux, but what about Windows?

Windows requires a partition table as far as I know. Either the old PCDOS style or the new GPT style. Of course malware can do as it will.

Also, could there be something bad in the MBR that could point to a filesystem not present in the partition table?

Now your thinking.

Maybe the safest course is to zero both the MBR and the label with dd?

It's a good start. Wiping the entire disk is much better (and what is done by many). If you can't wait for the entire drive to wipe, then wipe at least the first few MBs and the last several GB. I would actually worry as much about the end of the disk as I did the start. Overwriting the first few MBs of a drives is pretty common, so a smart virus writer might figure out a way to leverage a payload at the end of the disk that survives normal drive prep. No, I don't know how the leveraging would happen, but I hadn't thought about a grow backwards filesystem either before I read that a virus was maintaining one.

If it matters, the target disks are all SSD's.

Regards, Lew

Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org