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

[Gordan Bobic]

On 07/05/2012 06:48 PM, freebirds at fastmail.fm wrote:
> Gordan Bobic asked: "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?'
>
> I manually scanned at various times. Clam could not open files that Clam
> previously could open. Not a permissions issue. Clam also detected
> macros in word files that previously did not have macros.

If this was happening when you were booting off a LiveCD it _must_ have 
been a permissions issue on some level, be it POSIX, ACL or SELinux. 
There has to have been a root cause and it can't have been that 
difficult to pin down. I would put hacking/conspiracy in the last place 
when looking for a root cause of such an issue.

> Gordan Bobic wrote: "No sane security-conscious person should be using
> Windows these days, so my interest in a Windows bug-hunt is below 0."


> I
> agree. In February 2012, I shipped two netbooks to a computer security
> expert for forensics and to harden Linux. He didn't finish. In the
> meantime, three times I purchased the Acer Aspire One 722 and returned
> them within 14 days due to cracking of AMD's virtualization. In the
> meantime, I using Windows computers.

In my view, from what you have said so far, you haven't provided any 
evidence that virtualization was at fault. OOB remote console using 
default username/password - maybe. But not virtualization. Not saying it 
didn't happen - just saying that you haven't provided any evidence to 
support that hypothesis.

> Gordon Bobic, you made an excellent point that ARM reduces "the field in
> terms of what malware might actually be effective."
>
> Gordon Bobic asked: "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?

> I need GUIs. I
> don't know command line. Trash not showing up occurred and not being
> able to delete trash was a problem on all my netbooks.

That isn't conclusive evidence of anything. It could easily be a bug in 
gnome or the trash folder being actually deleted. I understand that you 
need GUIs but the functionality the GUI provides, on ANY OS, isn't going 
to be sufficient to do even the most basic troubleshooting. I would have 
thought that doing "ls -la" as root on the affected device would be the 
first thing to do. If you haven't even done that it is way, way too 
premature to start suspecting foul play.

> Gordon Bobic wrote: 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."


> Built in wifi and
> bluetooth are not the problem. Soldered wifi and bluetooth are the
> problem.

Which is what nowdays happens on most laptops and certainly on all phones.

> Combo wifi/bluetooth card have up to know been removable by
> unscrewing a screw. I use an USB network adapter. When the crackers
> procure the MAC address of my network adapter, I discard it and replace
> it with a new one. I never ever use bluetooth. I already posted cites on
> geolocating the MAC address of bluetooth and hacking into bluetooth even
> when it is in hidden mode.

Again, this is assuming that:
1) Your WiFi module has an exploit
2) They are sitting outside your house

1) is questionable, but if 2) is the case you most definitely have 
bigger problems.

And if 2) is the case, replacing the WiFi module will achieve absolutely 
nothing since as soon as you switch it on it's MAC will be visible 
during the AP handshake.

Also note that on most WiFi devices (and wired NICs for that matter) you 
can actually forge the MAC address to anything you like. In fact, wasn't 
there a discussion on this mailing list recently about how the NIC MAC 
address was being set via a uboot variable?

> Gordon Bobic wrote: "There is every chance that something much simpler
> and less convoluted was going on if you were being hacked."
>
> Just the opposite. More is going on. Evidence of being cracked is
> complete remote control of my netbooks.

Again, that sounds more like remote console.

> Netbooks not shutting down. Going to sleep instead.
 > I had to hold the shut off button to shut them off.

That is not an uncommon bug, both on Linux and Windows.

> WOWL (wake on wireless lan). No longer being able to boot to live
> DVDs.

BIOS option for booting off CD/DVD?

> Files in my home directory that were remotely deleted. Files in my
> home directory that were remotely infected. After I successfully eluded
> and relocated and turned on my netbooks, the geolocation of my netbooks
> were tracked.

How have you established that they were tracked?

> You don't need to believe that I being cracked.

It doesn't matter what I believe - I am merely pointing out that you 
have not provided any actual evidence that should be easily forensically 
available if that were the case. I understand that you cannot easily do 
that, particularly if the contents of these machines were worth of the 
amount of effort that would have been required. But you haven't really 
provided enough evidence to support what you are claiming. And with a 
hack that extensive, there should be tons of evidence.

> Nor am I asking for SW
> or OS help with the cracking. The reason I joined this mailing list was
> to obtain help in choosing a safe open netbook or board. And if one does
> not exist, to attempt to create one. I do not want to buy another i86
> netbook: Bios rootkits, firmware rootkits, TPM, Intel AMT and
> virtualization, AMD DASH and virtualization, HPA hidden partition in the
> hard drive where malware can hide, etc.

Well, depending on what part of the world you are in, Toshiba AC100 is 
easily the highest performing, best value machine you are likely to get. 
Tegra2, 512MB of RAM. Reasonable upgradability to make it livable with 
(screen, OC-able to 1404MHz from 1000MHz with a minor cooling mod, it is 
even possible to fit a very good USB SSD internally since SD/MMC 
performance is awful). In UK they go for ~ £170 on eBay, new. 
Unfortunately, the were never available in US or other parts of the 
world. They ship with Android, but they have been quite well community 
supported to run whatever you want. I run RedSleeve Linux on it. A LOT 
of people run Ubuntu on it. Google around about it, I'm sure you'll find 
plenty of information, including my articles on upgrading it.

Of the 512MB 64MB is dedicated to the GPU. You can scrape most of that 
back if you are using just the frame buffer driver. I have mine with 
510MB available for the OS, and it is remarkably livable with after 
applying a few tweaks and optimizations, even if you are running 
bloatware like Firefox.

> I am trying to choose between the Sunlike Allwinner netbook, the older
> Lemote Yeeloong 2A or the raspberry pi. Lemote emailed that the wifi is
> removable. Yeeloong nor raspberry pi have bluetooth nor TrustZone nor
> virtualization. Because the Yeeloong 2A was developed in 2008 it has
> older technology than the raspberry pi. Ben NanoNote would qualify
> except there is no Fedora, Debian or Ubuntu preinstalled in it or on a
> SDcard.
>
> I do fear TrustZone in Allwinner A10. I posted that Open Virtualization
> created software to make TrustZone
> safer.http://www.openvirtualization.org/open-source-arm-trustzone.html.
> Why would there be need for Open Virtualization software? Does
> installing Open Virtualization software for TrustZone make both
> uncrackable?

Sorry, I cannot answer that, I largely ignore virtualization features on 
hardware unless I specifically need it. I am still not convinced it is 
the virtualization features that are the source of your problems. I'm 
not saying they aren't, but you haven't yet provided a single shred of 
evidence to support that theory. I would be most interested in hearing 
about if if there is any.

The only exploit I am aware of that uses things like virtualization 
extensions was on Intel x86 chips that eploits a caching problem where 
the memory of the virtualization hardware is read-only, but it is 
possible to write to it in the CPU cache, and then execute it. You can't 
write to the hardware, but the execution fetches the data from the CPU 
cache, and thus breaches the hypervisor. But before that can happen the 
perpetrator has to have already breached your machine using a trojan of 
some sort. The nature of the exploit is privilege escalation - it isn't 
the sort of an exploit that would allow access in the first place.

Gordan