[Arm-netbook] ARM's OOB para-virtualization & FreeZone in A10?

[Gordan Bobic]

On 05/07/2012 17:21, freebirds at fastmail.fm wrote:
> Gordan Bobic asked: "Can you cite a vector by which on Linux the AV
> daemon running as root is unable to scan a file using the on-open
> hooks?"

> I do not know what an on-open hook is. I scanned a live rescue
> CD that had Clam preinstalled on it. I also scanned ClamWin portable on
> a flashdrive.

In order for AV to work without manually scanning everything, you need 
AV with on-access scanning. On Linux this requires specific 
configuration. On Windows you need to use something like ClamSentinel.

When you say you checked it, do you mean that you manually scanned it 
and Clam couldn't open the files? If so, that is likely a permissions 
issue. Or are you saying that it scanned OK but didn't detect any problems?

Either way, Clam isn't exctly the best AV tool out there. It is a 
passable bare minimum for those of use who cannot abide teletubby 
interfaces and wouldn't want to risk bloatware and bugware like CA or 
Norton (they are completely unremovable, utterly cripple performance and 
aren't that good at detecting malware either). MalwareBytes Anti-Malware 
(MBAM for short) I've had reasonably good experience with - if I have an 
extremely good reason to think the machine is infected and Clam hasn't 
found anything, MBAM usually finds the offending malware if it is there.

> Gordan Bobic asked: " And this also works on Linux? Can you cite any
> record of an exploit that is capable of this?"


> My removable media had
> windows USB worms and Linux USB worms. Conficker and Mazebat were the
> Windows USB worms. I do not know the names of the Linux USB worms.

No sane security-conscious person should be using Windows these days, so 
my interest in a Windows bug-hunt is below 0. I would, however, like to 
know which exploit these Linux worms might have used. Are there any 
known exploits that can do this? I am certainly not aware of any that 
don't require you to explicitly run the malware. Macros in documents are 
a different issue, of course.

You might want to try running on an ARM machine - that would greatly 
reduce the field in terms of what malware might actually be effective. :)

> I
> erased my HD, flashed my BIOS and reinstalled Fedora. I inserted my
> removable media which infected Fedora.  I checked the box show hidden
> files. I could not see the trash file on my removable media including
> the trash file on my Sansa Clip MP3 players. Thus, I could not delete
> the trash. Like conficker, this malware was hiding in the trash.

Or maybe something else was going on. You do understand that "Trash not 
showing up" is not exactly conclusive evidence. Have you looked at it 
from the command line?

> Gordon Bobic asked: "Would you care to elaborate on that? How would the
> buy-out of MIPS result in there being no more support for MIPS?"

> If AMD
> purchases MIPS, AMD most like would incorporate MIPS technology into its
> chips. Thereby, MIPS would have AMD-V (Virtualization Technology).

That is a pretty enormous leap of assumption.

> Gordon Bobic asked: Can you elaborate why exactly it is specifically
> virtualization extensions that are an issue?"


> Virtualization extensions
> and TrustZone are not the only privacy breaches I discussed on this
> mailing list. I also discussed tracking the geolocation of the MAC
> address on bluetooth and wifi cards. I did not purchase a DreamPlug
> because it's wifi and bluetooth are soldered onto the motherboard.

That is likely pushing paranoia to a somewhat unhealthy level. So you 
are concerned about any hardware with built in WiFi and BT? That rules 
out just about any laptop and phone for a start. Is there a known vector 
by which this could be exploited without breaching your machine first? I 
am discounting the case where somebody is actually sitting in a van 
outside your house because in that case they already known where you live.

> Gordon Bobic asked: "If you are running a Linux kernel that will only
> load signed modules, how do you propose the perpetrator would
> inject a custom, unsigned virtualization module into your running kernel
> to leverage virtualization extensions to do something nasty to the
> running OS?"

> I do not know.

Until this can be clarified and connected with a known exploit with any 
sort of documentation, I'm inclined to dismiss it as hearsay. There is 
every chance that something much simpler and less convoluted was going 
on if you were being hacked.

Or to put it another way - show me a single shred of scientifically 
collected hard evidence.

Gordan