Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Attacking Sandboxes

kdawson posted more than 7 years ago | from the just-another-brick-in-the-wall dept.

Security 110

SkiifGeek writes "Many anti-malware applications use a sandbox as a tool to help identify potentially malicious software. Now knowledge is spreading about techniques and methods that can allow sandboxed software to target the sandbox itself (and by extension the application that applied it). While attacks that specifically target sandboxing applications are probably a little way off, this technology can be considered the logical extension of techniques and procedures to identify the presence of hosted systems (VMWare, Virtual PC, etc.)."

Sorry! There are no comments related to the filter you selected.

Enter the Sandbox (2, Funny)

Anonymous Coward | more than 7 years ago | (#19871731)

So when will we be able to attack the Matrix?

Sandbox the sandbox (4, Funny)

robo_mojo (997193) | more than 7 years ago | (#19871733)

That's ok. We can just sandbox the sandbox and still be safe.

Re:Sandbox the sandbox (4, Funny)

langelgjm (860756) | more than 7 years ago | (#19871833)

But who will sandbox the sandboxers?

Re:Sandbox the sandbox (4, Funny)

ehrichweiss (706417) | more than 7 years ago | (#19872307)

HA! I got you on that one!!! It's sandboxes all the way down!!!!!

Love this -- like the turtles.... (4, Funny)

CFD339 (795926) | more than 7 years ago | (#19872733)

Just remember....recursive code is great code, because its recursive, so its great.

Re:Love this -- like the turtles.... (4, Funny)

ettlz (639203) | more than 7 years ago | (#19874073)

Just remember....recursive code is great code, because its recursive, so its great.
Well I'd just like to point out thaStack overflow
Aborted

Re:Sandbox the sandbox (2, Funny)

sunami88 (1074925) | more than 7 years ago | (#19873583)

When sandboxes are outlawed, only outlaws will have sandboxes.

Oh Slashdot, your memes are teh win.

Re:Sandbox the sandbox (0)

Anonymous Coward | more than 7 years ago | (#19874679)

In Soviet Slashdot, teh win memes you!

Re:Sandbox the sandbox (4, Funny)

GizmoToy (450886) | more than 7 years ago | (#19871861)

You know, this was marked as Funny but I wouldn't be surprised if this was suggested as a solution at some point. "Hell, just wrap it in another (insecure) layer and it'll be fine."

Re:Sandbox the sandbox (5, Interesting)

CastrTroy (595695) | more than 7 years ago | (#19872345)

Sounds like the security methods most online banking systems use. Here's the current layers:
  • password
  • mother's maiden name/ what's you're favourite movie
  • secret picture
  • randomized keypad for entiring password

It's all layers of useless crap piled on top of eachother which doesn't stop the real problem of people falling for stupid fishing sites, and entering a password in a site that looks like their bank's. If they really wanted to add real security they'd hand out RSA key fobs to everyone instead of adding layers of stuff that makes it look more secure but actually isn't.

Re:Sandbox the sandbox (3, Insightful)

billcopc (196330) | more than 7 years ago | (#19872783)

So you're saying the RSA key fob isn't another useless insecure layer of crap ? Have you even HEARD their sales pitch ?

Re:Sandbox the sandbox (3, Insightful)

Poltras (680608) | more than 7 years ago | (#19872827)

as long as USERS don't understand it, yes it is useless. Secure the communication and provide X509 certs all you want, if the user think it's a bank, he will enter his password.

Re:Sandbox the sandbox (2, Insightful)

mcrbids (148650) | more than 7 years ago | (#19874147)

as long as USERS don't understand it, yes it is useless. Secure the communication and provide X509 certs all you want, if the user think it's a bank, he will enter his password.

I don't think you understand what he's really saying - you could hand out RSA key fobs and/or client certificates that authenticate the browser to the bank. Without that, the password would/could be utterly useless.

If the bank uses the key fob, you can't enter by password alone. If the bank uses client certificates, then that must be installed on the browser first. (much more difficult than just lifting a password)

Now, if only they made it easier to set up client certificates...

Re:Sandbox the sandbox (2, Interesting)

0xygen (595606) | more than 7 years ago | (#19874297)

How does prevent the existing real time man in the middle attack?

e.g. user visits phisherman's site, phisherman's server visits bank, passes on RSA auth request to user's browser, user's browser passes auth request back to phisherman, who passes it to bank. Phisherman now logged on as user?

Re:Sandbox the sandbox (1)

gnasher719 (869701) | more than 7 years ago | (#19874777)

'' I don't think you understand what he's really saying - you could hand out RSA key fobs and/or client certificates that authenticate the browser to the bank. Without that, the password would/could be utterly useless. ''

A very low-tech approach would be this: On your paper bank statement that you receive every month, print a list of twenty 10-digit access codes. Each access code can be only used by you, in the following month, and only once. One month delay so you can tell your bank if the statement didn't arrive or looked tampered with. There would still be some danger that someone could steal _one_ access code via fishing, but not more.

Re:Sandbox the sandbox (1)

Random832 (694525) | more than 7 years ago | (#19875317)

So what do you propose to do after you log in twenty times in a month?

Re:Sandbox the sandbox (1)

murukusu (893892) | more than 7 years ago | (#19877227)

Here in Finland we have a system where the bank sends 80 one-time passwords to the customer along with 18 reusable passwords. To log on into the bank's website you need your customer id with the one-time password. To do anything in the website, eg pay the bills or do a money transfer to another account, you need to accept the transaction with one of the reusable passwords. When you've reached 60th or so of the passwords the bank sends you a list of the next 80 passwords. I feel it's secure and quite easy to use a system

Re:Sandbox the sandbox (1)

Lord Ender (156273) | more than 7 years ago | (#19876245)

Phishers can still MITM two-factor authentication. OTP methods, like SecurID, and smartcard authentication (hardware-based client X.509 certs), can be forwarded on to a bank if you get the user to go to a bogus site.

Re:Sandbox the sandbox (2, Informative)

arminw (717974) | more than 7 years ago | (#19873245)

..... If they really wanted to add real security they'd hand out RSA key fobs to everyone......

Does that mean the use is restricted to the users own computers or any others that has the correct interface and software which is able to send the key-fob data to the bank's server at the correct time?

A password will work with *any* computer, but a piece of hardware, whether key-fob or biometric scanner will only work with a computer that has the correct software installed on it. That software would have to be standardized and work with every OS and all hardware that can at present access the bank's systems wit a password. All security, computer or physical, ultimately based on something you know, or something you have or both.

Re:Sandbox the sandbox (1)

TheLink (130905) | more than 7 years ago | (#19874055)

No. It's restricted to people who can submit the correct username and password, and correct number from the keyfob, in the three fields on the bank's login form, within X minutes for when the number from the keyfob is valid.

Alternatively, if you have a smart keyfob, you punch in your password (cached for say 5 minutes) and then out comes some new number which you then use to log in.

There are plenty of other alternatives - ask the crypto people.

Still you do not want to be using an untrusted computer since once you are logged in, the malware will presumably get the resulting cookie and could do the naughty stuff secretly (BUT some banks require you to revalidate for important stuff like transferring money).

Re:Sandbox the sandbox (2, Funny)

Mike89 (1006497) | more than 7 years ago | (#19873885)

falling for stupid fishing sites
Yeah, somehow these places always manage to hook me with their bait.

Re:Sandbox the sandbox (0)

Anonymous Coward | more than 7 years ago | (#19875705)

Key fobs are nice. They are good for stopping replay attacks. However, you can still do a man-in-the-middle type
fishing attack despite them, since all you're doing is passing on the credentials. SSL/TLS certificates on the otherhand
are a good way of verifying a websites identity and therefore contribute far more in stopping fishing attacks.

 

Re:Sandbox the sandbox (1)

owlstead (636356) | more than 7 years ago | (#19879015)

"If they really wanted to add real security they'd hand out RSA key fobs to everyone instead of adding layers of stuff that makes it look more secure but actually isn't."

Bah, all banks in the Netherlands, and most of Europe, do this. Either that or they rely on mobile devices or one time codes to do secure login and transaction authentication. If they didn't, I would switch banks. Although the security devices here are delivered by a company named Vasco. The devices are not connected to the PC as you indeed mention in a reply on a reply. Time for the US banks to catch up.

Re:Sandbox the sandbox (1)

CastrTroy (595695) | more than 7 years ago | (#19879175)

Are such things legislated into existence, or are the people running EU banks just that much more informed about what the real solutions are? Are there different laws for who is held accountable when money goes missing from someone's account? It seems to me like the US/Canadian banks are just trying to make things cheaper, and that, left to make their own decisions, the European banks would have the same crappy security. Is there any reason that the European banks would have something like this. Is it something the customers asked for? Or something that they are required to have?

Re:Sandbox the sandbox (2, Interesting)

Meski (774546) | more than 7 years ago | (#19872415)

When the real layer is equally insecure, how will you know you have reached it?

Re:Sandbox the sandbox (1)

Gregb05 (754217) | more than 7 years ago | (#19871991)

This article seems to be a bit of FUD to me.
Most of the sandboxed systems it refers to in the article are anti(virus/spyware/malware) programs. If the machine is already compromised with some malware, there's no real incentive for a virus to become active only when Symantec's VM runs across them. If it's already on the system, there's no limit to the damage a file could do through other (more direct) methods.

Referring to a cousin comment, it's probably better for the malware to lay low when scanned rather than to take advantage of the virus scanner.

Re:Sandbox the sandbox (2, Insightful)

Miseph (979059) | more than 7 years ago | (#19872611)

Because the AV/S/M app is frequently able to obtain all sorts of wacky permissions and access, it could be viable to piggyback on it into otherwise secure systems. For example, if an AV was set up such that it could scan encrypted data, then exploiting it to get past the encryption could be feasible.

Over coming sandboxing (1)

zoomshorts (137587) | more than 7 years ago | (#19872871)

What you need to run, in order to overcome sandboxing, is my handy
utility called Cats(TM). It will effectively pollute any benefits of
sandboxing. In addition, it will spawn child processes Kittens(TM) to
further confuse the processes.

Serves us right (3, Funny)

jimbug (1119529) | more than 7 years ago | (#19871777)

for building a box out of sand. what were we thinking?

Re:Serves us right (2, Funny)

RAMMS+EIN (578166) | more than 7 years ago | (#19872327)

I thought sand was central to most boxen.

Well, silicium, anyway.

Old news (4, Informative)

Nick_taken (1090721) | more than 7 years ago | (#19871819)

Theres a simple detection program called RedPill that probes a simple method to do so, vmware leaves a lot of registry keys on windows, VirtualBox lacks supports for hardware breakpoints, cpu cycles counts is another way to detect virtualization, and some packed malware dont even run on virtual machines because of memory management, software packed with armadillo do not run on vbox and it used to fail on vmware player until they fixed that bug.

"Thwarting Virtual Machine Detection" is a nice paper on virtual machine detection.

Re:Old news (2, Insightful)

QuantumG (50515) | more than 7 years ago | (#19872161)

It's pretty trivial to find a dozen ways to detect a virtual machine, just make a project that generates some random bytes and then jump to the bytes. Put the program in a script that calls it over and over again with a seed for the random number generator. When the VM crashes, look at the last seed that was used. Run the program again with that seed to confirm it is repeatable. This also happens to be a good way to detect if your VM is any good and fix it when it isn't. Unfortunately, many things are just so obscure on the x86 architecture that fixing all these bugs is just a chore that doesn't get you any big payout (as no real code uses these obscure things) so most VM developers don't bother.

Re:Old news (0)

Anonymous Coward | more than 7 years ago | (#19872453)

Some time ago, I managed to bust out (uncontrollably) from the VMWare Server guest box. The trick I found required megabytes of code and ring-0 control of the guest machine. It involved a bug in v86 emulation that would propagate outwards in a manner I never could fully characterize.

What I did:
1. Installed MS-DOS 6.2
2. Installed Windows 3.1 (the Win 3.1 Y2K patch is slipstremed into my install disks).
3. Installed Win32s with the FreeCell sample shipped for developers.
4. Executed FreeCell. This crashed Win3.1 back to a DOS prompt.
5. Executed mem /c. This crashed.
6. Rebooted the VM. This rebooted the host as often as not.

I suspect the bug lies somewhere in emulating the (probably insane) CPU state the machine is left in after that sequence.

Re:Old news (1)

bluephone (200451) | more than 7 years ago | (#19874031)

VMWare doesn't have any tools for DOS, so they recommend a third party tool called DOSidle so that when DOS is, well, idle, it won't continue to suckup 100% CPU doing nothing. It sounds like your hack is exploiting that flaw as well as 16/32bit thunking and memory emulation flaws. This is, mm, interesting. I'll have to play with this. On a box that I don't mind being rebooted spontaneously. ;)

Re:Old news (2, Interesting)

AndroidCat (229562) | more than 7 years ago | (#19874803)

I remember when Lotus 1-2-3 had code designed to crash if was run with debug.

Strike vs Counterstrike (5, Insightful)

mcrbids (148650) | more than 7 years ago | (#19871821)

There will never, ever be an end to this.

As long as people are imperfect (and they always will be) there will be measures, countermeasures, and counter-counter measures. New techniques will make old ones obsolete, and even newer techniques will make the once-new techniques no longer apply.

With this understanding, any technology that can outsurvive more than one or two iterations of other products in the same field becomes "venerable" and "stable".

Which makes now a particularly good time to appreciate the guys who worked out the spec for TCP/IP some 30 (?) years ago. Despite going from mainframes, to minis, to PCs, and now on to the era of ubiquitous computing, the basic concepts and ideas behind the TCP/IP specification continue to hold steady and useful. They managed to come up with a technology, that whatever flaws have actually been found, hasn't come up against any real show-stoppers. None.

To which I can only say: WOW.

Re:Strike vs Counterstrike (0)

Anonymous Coward | more than 7 years ago | (#19872051)

As long as people are imperfect (and they always will be)

Speak for yourself. I consider myself as a perfect being. Thank you very much.

Re:Strike vs Counterstrike (1)

QuantumG (50515) | more than 7 years ago | (#19872119)

uhhh.. TCP hijacking is almost just as easy now as it was 10 years ago. Back then you didn't have a whole lot of switches (they were much more expensive than hubs) so you could sniff packets for other hosts easier, but the act of hijacking TCP connections is still a major flaw in the protocol. We just work around it.

Re:Strike vs Counterstrike (1)

imemyself (757318) | more than 7 years ago | (#19872265)

Back then you didn't have a whole lot of switches (they were much more expensive than hubs) so you could sniff packets for other hosts easier,

Would that really be considered a flaw in TCP/IP though? That's really Ethernet's (L2/L1) fault, TCP/UDP (Layer 4) and IP (Layer 3) aren't really involved with hubs/non-L3 switches (Layer 1 and 2 respectively).

On another note:

How many of the major flaws/security issues have been entirelly the fault of the protocol's specification? I honestly don't know, I usually don't look that much into the details about security flaws, but it would seem like more of the problems would be in the implementation of the protocols.

Re:Strike vs Counterstrike (2, Insightful)

QuantumG (50515) | more than 7 years ago | (#19872305)

It's not about being able to sniff packets. That just makes it more applicable because, back then, you didn't need to be upstream. Today, if you're upstream of an end point you can hijack a TCP connection.

Re:Strike vs Counterstrike (1)

Johnno74 (252399) | more than 7 years ago | (#19872439)

I thought that TCP hijacking was possible because of vulnerbilities in Sequence number generation in some TCP implementations, which have now been fixed?

Re:Strike vs Counterstrike (1)

QuantumG (50515) | more than 7 years ago | (#19872517)

That's only the case for blind TCP hijacking.

Re:Strike vs Counterstrike (3, Insightful)

mcrbids (148650) | more than 7 years ago | (#19873909)

TCP hijacking is almost just as easy now as it was 10 years ago.

It may be even easier. Who cares? However you look at it, TCP is doing its job. If you want to prevent against hijacking, the layered topology of the communication stack lets you prevent that at a higher level. (EG: Using encryption - which can be interrupted, but not hijacked)

TCP hijacking is merely a side effect of a missing layer in the stack of your application.

Re:Strike vs Counterstrike (1)

TheLink (130905) | more than 7 years ago | (#19874071)

If you can't do blind hijacking then TCP is fine and doing it's job.

Just use SSL if you want more security. There's no point paying the extra cost of encryption when you don't need it.

You need to do lots of extra stuff (check certs etc) if you do not want to be hijacked by MITM attacks.

Re:Strike vs Counterstrike (0)

Anonymous Coward | more than 7 years ago | (#19872527)

There will never, ever be an end to this.

Only if you never, ever learn thermodynamics. [wikipedia.org]

Sandboxes and Firewalls (2, Funny)

Sammy Loo (996666) | more than 7 years ago | (#19872715)

People will start to think of sandboxes like they do fire walls. (Hay its wallz of fires! hay im no0b!)

hahahahahahhahahahahaha

I hate when people do that.

Re:Sandboxes and Firewalls (0)

Anonymous Coward | more than 7 years ago | (#19873693)

Security comes in layers, but it's important not to build your firewalls too tightly around your sandboxes or vice versa. The reasoning behind this is that sand is known to put out fires. Even when these two technologies are deployed properly this is usually not enough to secure a computer system, as both suffer from the same weakness: water.

Re:Strike vs Counterstrike (1)

bluephone (200451) | more than 7 years ago | (#19874043)

I'd have to say that's because they designed a solution that was compact, well defined, and didn't overreach and try to solve world hunger. They just designed a solution to the problem at hand. When your project starts trying to solve problems that you didn't start out to solve, that's where issues creep in. It's the /other/ downside to feature creep. Creeping features have creeping bugs. I'm a sucker for well compartmentalized and focused design.

Re:Strike vs Counterstrike (1)

moderatorrater (1095745) | more than 7 years ago | (#19874053)

I'm a sucker for well compartmentalized and focused design.
And that's why you'll never advance in the company.

Re:Strike vs Counterstrike (1)

bluephone (200451) | more than 7 years ago | (#19880267)

That's why I work for myself. :)

Re:Strike vs Counterstrike (1)

Errtu76 (776778) | more than 7 years ago | (#19874311)

CS .. now WoW ... are you sure you're posting in the right thread?

Re:Strike vs Counterstrike (1)

master_p (608214) | more than 7 years ago | (#19875061)

There will never, ever be an end to this.
It all depends on the host architecture: if it's properly engineered, then malware wouldn't even be a possibility. But as it is right now, PC operating systems are random bits of code thrown together without a clear architecture with security in mind. The overall PC architecture does not lend a hand to security.

Once again, they didn't read the article. (5, Insightful)

Cafe Alpha (891670) | more than 7 years ago | (#19871883)

The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.

It also said that software has been found that detects when it's attached to a debugger. Big deal, copy protection schemes have been doing that for decades.

The article then goes on to FUD that code that attacks the sand box "must" be coming.

Oh, it must be coming. Uhuh.

Re:Once again, they didn't read the article. (0)

Anonymous Coward | more than 7 years ago | (#19871923)

This should be modded up. Malware has no intention of ever attacking Sandboxed systems. User's who are running them are likely to be highly competent developers or highly paranoid. Either way, attacking said system has a prohibitive effort/pay-off ratio.
Being ignored, or simply delaying detection will have its advantages, as the malware avoids detection and study, allowing it to spread to other, more cost-effective users.

Re:Once again, they didn't read the article. (1)

moderatorrater (1095745) | more than 7 years ago | (#19874063)

Yes, that may be the case right now, but at one time the internet was the domain of the highly competent developers and look how that turned out.

Re:Once again, they didn't read the article. (0)

Anonymous Coward | more than 7 years ago | (#19871929)

The article doesn't mention it, but VMware has had bugs that let malicious code "escape" onto the host. An example. [securitytracker.com] Virtual machines aren't perfect.

Re:Once again, they didn't read the article. (1)

xigxag (167441) | more than 7 years ago | (#19873461)

Interesting. So is there a way to SIMULATE running in a sandbox - in terms of a simple program could be installed by Joe Idiot and use up very few cpu cycles, so that the malware would believe the system was being sandboxed and thus behave innocently?

Re:Once again, they didn't read the article. (1)

TheLink (130905) | more than 7 years ago | (#19874083)

Sure that's called running stuff in a sandbox with hardware sandbox support.

Just wait till Intel VT and AMD Pacifica improve.

Re:Once again, they didn't read the article. (1)

Lord Kano (13027) | more than 7 years ago | (#19873951)

The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.

How long before someone codes up a hack to make a real instance appear to be a sandbox so that malware will go dormant?

LK

Re:Once again, they didn't read the article. (1)

FreakyLefty (803946) | more than 7 years ago | (#19874885)

The article then goes on to FUD that code that attacks the sand box "must" be coming.

Verbing weirds acronyms.

Re:Once again, they didn't read the article. (1)

A non-mouse Coward (1103675) | more than 7 years ago | (#19877771)

Right, but if you think about how a person would determine if software was bad...

Imagine that an "analyst" is either not allowed to use automated tools or that s/he doesn't have any (but if s/he doesn't have any, why do this? Just bear with me...). If the analyst looks at each instruction and maps them all out, the analyst would then be able to see if the software is benevolent or malevolent. The analyst could also see if the software attempts to determine if it's running in a VM, etc.

This is why I think that, in the end, only a lazy analyst could be defeated (i.e. one that isn't looking closely at the instructions or at all of the instructions hitting the CPU). And if a human can do it, we could certainly build better automated tools to work more slowly and under less assumptions, asking the human analyst for input as necessary.

Umm... yes? And? (5, Interesting)

Opportunist (166417) | more than 7 years ago | (#19871985)

That malware detects VMs is old news. I'd wager about 60% of current malware has VM detection built in. About as many have debugger detection. Some overlapping allowed.

So far, malware that "breaks out" of the sandbox would be new to me (though I'd be grateful for a sample). Though, seriously, why not run a VM with Windows (to analyze) on a box running Linux? I'd be very interested if someone manages to do the feat of creating a piece of malware that manages to break out of the sandbox and then run on a machine with a completely different operating system.

If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it.

Re:Umm... yes? And? (0)

Anonymous Coward | more than 7 years ago | (#19872443)

Stealth (i.e. undetectable) debuggers seem possible in principle. The only one I know about is
Cobra [uta.edu] . Unfortunately it looks proprietary and closed source.

If anyone knows of free-software stealth debuggers I'd like to hear about them.

Re:Umm... yes? And? (1)

martin_henry (1032656) | more than 7 years ago | (#19873819)

I'd wager about 60% of current malware

Are you saying that you own over 60% of current malware?

Re:Umm... yes? And? (1)

LittleBigLui (304739) | more than 7 years ago | (#19874081)

Are you saying that you own over 60% of current malware?


It's just too tempting:
In soviet russia, malware pnws YOU! :)

Re:Umm... yes? And? (2, Funny)

Opportunist (166417) | more than 7 years ago | (#19874359)

Actually, forget the "in soviet". "Russian malware pnws YOU!" is more to the point.

Re:Umm... yes? And? (1)

Opportunist (166417) | more than 7 years ago | (#19874369)

Well, you know, some collect stamps, some collect trading cards... hey, everyone needs a hobby.

Re:Umm... yes? And? (1)

teh_chrizzle (963897) | more than 7 years ago | (#19878845)

why not run a VM with Windows (to analyze) on a box running Linux? I'd be very interested if someone manages to do the feat of creating a piece of malware that manages to break out of the sandbox and then run on a machine with a completely different operating system.

you are right, the point of using virtualization is to isolate applications from one another and the host operating system, but that is not the only security feature provided by virtualization.

the article fails to mention that most virtualization packages let you take snapshots of a running system and move machines to and from different physical hosts.

the worst hypothetical case would be for malware to break out of the VM and infect the host, causing the host to infect other VMs. malware would have to break out of the compromised VM, break into the host, and then break back into the other VMs running on the host... now my brain hurts :-(

even if this "doomsday scenario" were to come to pass the damage done could be mitigated thanks to virtualization. once a VM was determined to be infected, you could stop it in place and check your host. if the host is determined to be infected, you could stop all your other VMs and migrate them to an alternate host which is known to be malware free. any infected hosts could be restored from non-infected snapshots as soon as the files were copied to the proper location.

If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it.

i think that emulating one chip architecture while running on another would impact performance significantly. i used to use kju [kju-app.org] to run a win2k machine on my mac G5 tower and the machine worked but it was hella slow. winXP on an intel based macbook pro was significantly faster.

Re:Umm... yes? And? (1)

owlstead (636356) | more than 7 years ago | (#19879147)

"If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it."

I don't see what kind of difference this makes. It's pretty easy to compile stuff to run on multiple platforms. I don't see how it is any more difficult to break out of a virtual box running xxx and infect yyy than it is to break out of xxx and infect xxx. Much of the same VM code - including bugs and flaws - would be in both xxx and yyy, and recompiling is - well - easy.

Watch what I can do (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19871995)

Ya know, this has been around for a while: a few friends of mine know how to target the host of a sandbox through viruses and whatnot... nothing new here except some retard realizing whats happening to him. What losers.

Re:Watch what I can do (4, Funny)

click2005 (921437) | more than 7 years ago | (#19872037)

I've got friends who know how to block your friend's actions.

oh, yes (0)

Anonymous Coward | more than 7 years ago | (#19872085)

If you'll review the vmware source,
you'll see, about line 452 of vm_ostat.c,
that there is a major flaw.

This might be good for end-users (1)

tkrotchko (124118) | more than 7 years ago | (#19872107)

Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.

By the same token, it suggests a new attack against malware.... find out what makes a piece of malware think it's running on a VM and then make a physical machine react the same way. The possibilities are endless here.

Re:This might be good for end-users (1)

CastrTroy (595695) | more than 7 years ago | (#19872385)

Well, it isn't the point of VMWare and Parallels to ensure that it isn't detectable. A simple check of the video card driver or something else similar will show that it is indeed a virtual machine. If you wanted to build a VM that was much harder to detect, then it could be done. But instead VMWare et al have other priorities such as increasing the efficiency and adding management functions. If you have malware installed on your ESX server, then you got more issues then whether or not it can detect that you are running in a VM.

Re:This might be good for end-users (1)

arminw (717974) | more than 7 years ago | (#19873449)

........A simple check of the video card driver or something else similar will show that it is indeed a virtual machine.......

Not if the VM is emulates the actual HARDWARE accurately. Ultimately, if the emulation software is written to behave EXACTLY the same way the hardware it is emulating, there can be no SURE way any software running under that emulator can determine whether it is running on real hardware or not. Modern microprocessors are combinations of hardware and software also. The software part is called microcode, intimately associated with the actual gates and switches that make up the elements of every computer.

It may not always be very efficient to emulate all hardware functions. Any software running on such an accurately emulated machine might be able to tell from the slower timings for certain operations, that it was running on a machine too slow for the kind of hardware the emulator is supposedly telling the software which is running such detection routines. However the software could not be SURE whether is wasn't running on real hardware on which the speed was deliberately throttled.

VM makers of course are interested in efficiency. Making an undetectable VM accurately mimicking hardware probably would sacrifice too much efficiency.

Re:This might be good for end-users (1)

Lord Kano (13027) | more than 7 years ago | (#19874007)

Not if the VM is emulates the actual HARDWARE accurately.

VMWare emulates the same video and sound cards. All one has to do is check for the specified hardware. Look for the hardware emulated by VMWare and if you find it, turn off certain "functionality".

LK

Re:This might be good for end-users (1)

arminw (717974) | more than 7 years ago | (#19878347)

......All one has to do is check for the specified hardware. Look for the hardware emulated by VMWare and if you find it, turn off certain "functionality"......

If that were done, then the real hardware in other systems would also be detected. That means if the VM emulated really popular hardware, the detector would give many false indications for the real hardware the potential malware would otherwise infect..

Re:This might be good for end-users (1)

kma (2898) | more than 7 years ago | (#19877517)

Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.

Why would it be an improvement on our (I work for VMware) products to make them undetectable? To the extent that malware disables itself in the presence of a VMM, VMMs only become more attractive for production use. Not all PCs are alike, and we make no effort to hide it, and yet the world continues in peace. We don't make any effort to hide the chipset, the vendor/model/stepping of the CPU you're using, the particular version of the vendor's BIOS, or the version and patches of the kernel. Why should a VMM be any different? I think we should just consider the virtual machine monitor another piece of the hardware/software stack on which you happen to find yourself running. In the long run, the arms race between "stealthy" VMMs and VMM detectors is hopelessly skewed in favor of the detectors, anyway.

Re:This might be good for end-users (1)

tkrotchko (124118) | more than 7 years ago | (#19878727)

I see it as an improvement in the entire virtual machine evolution. Why can't virtualized machines emulate any given set of hardware? I want to look like a P3, or a P4, or something newer? It would be nice to make random piece of hardware visible or invisible to allow the virtual machine access to hardware (or not) as desired. I'd like to ability to hide from my software that it's been virtualized.

As to VMWare, it's a great product, I've bought it and I use it, but the way it virtualizes CD's/DVD's, USB's and other hardware needs to be improved. Maybe the market is geared towards server virtualization. That's fine, but I'd like a lot more ability to control and configure the virtualized machine. Maybe I don't want it to emulate an S3 video card. Maybe I'd like it to emulate a USB sound card. More flexibility is better.

You Don't Even Need Special Code to Detect VMwa... (1)

Comatose51 (687974) | more than 7 years ago | (#19872271)

To detech VMware, it's almost trivial. VMware can be detected with a built-in backdoor. The backdoor is a configurable setting that's on a lot of times. Programs like VMware Tools use it to enhance KVM operations. An easier check would be to look on the system to see if your network driver is the VMware NIC drivers.

"Piercing the abstraction" as they call it in the business, however, is much more difficult especially on a VM running on top of VMware's ESX, which don't actually interact with the guest OS except via software that uses the backdoor. If it is turned off, VMware doesn't talk to the guest OS so I don't see an easy way of doing this. VMware works by intercepting special system calls and getting out of the way and allowing the VM to execute its code on the CPU itself.

Solutions like paravirtualization would be more susceptible to these attacks than a hypervisor like VMware.

Re:You Don't Even Need Special Code to Detect VMwa (1)

QuantumG (50515) | more than 7 years ago | (#19872375)

Setup a callgate, call it, the exceptions generated will be subtlety wrong. There's a lot of real weird stuff in the Intel instruction set that VMWare doesn't even try to emulate because the only OS that uses even 1% of it is OS2.

These are so called WONTFIX bugs.. all VMs have them. There ain't enough hours in the day to worry about every nook and cranny of the x86 architecture.

Sand Toys (1)

DanMelks (1108493) | more than 7 years ago | (#19872285)

So the little tykes are refusing to play nice in the sand box, so add some sand toys. I always wanted one of those little shovel things.

Question to those who sandbox (1, Interesting)

Anonymous Coward | more than 7 years ago | (#19872315)

Malware's built-in detection makes hell of the casual e-sleuth's investigation techniques, and there seems only one sure-fire way to make sure malware behaves as you wish; keep it on a real system. I'm mostly speaking of network-oriented malware (ie: botnet clients), where you don't really care so much about what goes on with the infected system, so much as what occurs during the control/attack phase.

So, does anyone know of a particularly home-friendly way to handle a real-hardware box? I'm not sure of the best way to do this, but I assume it may simply require a CD/DVD that boots windows, instead of re-imaging the drive every time you want to test something new (which sounds quite...painful).

Great timing. :( (0)

Anonymous Coward | more than 7 years ago | (#19872401)

My wife just stormed out of the house, after we had an argument over whether Slashdot is "professional" for me or just encourages "antisocial views and behavior". I bet her that if we browsed to Slashdot RIGHT NOW the first headline would be NEWSWORTHY and NOT antisocial. "Attacking Sandboxes". Thanks a lot.

Re:Great timing. :( (0)

Anonymous Coward | more than 7 years ago | (#19872407)

Yeah, you've a wife. brb, milking my girlfriend

Smells like MS FUD to me. (0, Flamebait)

opieum (979858) | more than 7 years ago | (#19872537)

This sounds like MS FUD to me. Considering that their aim is to stop virtualization (if they are not doing it on their crippleware). It makes their OS irrelevant. And the increasing amount of reports on how virtualization is helping build leaner more efficient server farms and the like bolster this.

This reeks of MS tactics. No proof yet but I am sure it will come out eventually. It usually does. I would not be surprised if they indirectly had something to do with finding these vulnerabilities. MS Fanbois flame away.

Re:Smells like MS FUD to me. (0)

Anonymous Coward | more than 7 years ago | (#19872579)

No, this proves VMs have an advantage over regular hardware; they are resistant to malware.

This has been proposed in 1980s science fiction (0)

Anonymous Coward | more than 7 years ago | (#19872625)

An idea similar to this was proposed in 1980s science fiction. In particular, Eternity by Greg Bear [gregbear.com] had a computer virus that could escape any sandboxed environment.

All I saw was... (1)

DelitaTheFridge (912659) | more than 7 years ago | (#19872811)

Sandbox Sandbox Sandbox

Re:All I saw was... (1)

Taleron (875810) | more than 7 years ago | (#19873133)

Developers, Developers, Developers?

Detecting virtualization? (3, Funny)

macemoneta (154740) | more than 7 years ago | (#19872821)

Being able to detect virtualization would be great, if the technique can be generically applied [wikipedia.org] .

There is no spoon [wikipedia.org]

Arms race for nothing (1)

billcopc (196330) | more than 7 years ago | (#19872835)

I've always said it, and I'll keep saying it until malware takes my baby away, but every time someone makes a smarter anti-virus, some teenager will create a better virus. It's the computer equivalent to pesticide: it kills one batch of bugs, but the next generation grows immune.

Meanwhile, I avoid ALL forms of anti-malware tools, and magically I rarely get infected. When I do, I notice pretty quickly because I actually pay attention to what my PC is doing. If a certain task (or game) is used to running smoothly, and all of a sudden it starts wigging out, I'll know something is up. It's not like malware has ever cared to be spartan when it comes to CPU and memory usage.

If McAfee could stop selling anti-virus software, and instead just sell a book or instructive video on how to not be stupid and how to not click on all those sexy ActiveX prompts, well first of all they'd go out of business because they're a sloppy ass company, but secondly maybe some people would actually develop the ability to not click everything under the sun.

As it stands, I am of ZERO value to malware authors because my PC doesn't get involved in their spam/botnets, nor do I spread the plague to my friends and coworkers. I'm also worth ZERO to the anti-virus companies. If more people could self-police their PC like me, it would put a dent in both the virus and anti-virus businesses and as a result, it would slow the evolution of malware.

If two kids are fighting over a silly toy, when you take away the toy, they find something else to occupy them. Virus authors are no different. Businesses are no different. Humankind as a whole is no different.

Re:Arms race for nothing (3, Interesting)

dbIII (701233) | more than 7 years ago | (#19873193)

Meanwhile, I avoid ALL forms of anti-malware tools, and magically I rarely get infected. When I do

Isn't once enough for anyone? You did format and restore from a known good backup or install media afterwards didn't you? There's a tendency lately to trust that whoever had full control of your PC did nothing but run a set script and blindly hope that there is nothing else on there. I've played with various removal tools when people have given me compromised machines and different tools gave me different answers the other tools could not detect - perhaps there were some things neither could detect, hard to be sure especially when you are booting from a compromised system.

Fdisk it from orbit - it's the only way to be sure.

Re:Arms race for nothing (4, Insightful)

bmo (77928) | more than 7 years ago | (#19873549)

"Fdisk it from orbit - it's the only way to be sure."

Even Microsoft agrees with you. You can't "clean" a compromized machine.

http://www.microsoft.com/technet/community/columns /secmgmt/sm0504.mspx [microsoft.com]

That goes for other OSes too.

--
BMO

Re:Arms race for nothing (1)

Random832 (694525) | more than 7 years ago | (#19875419)

That article goes a bit too far:

You can't clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies.

How exactly are these tools going to start running, when the system is booted to the install CD rather than the hard drive? I mean, by that logic the attacker could have tools in place to tell fdisk lies, too, so the only option is to literally incinerate the disk and buy a new one. Unless the attacker managed to flash your bios, you're probably safe here. And if that did happen, then you're completely screwed.

Also, the issue of having tools to tell an antivirus tool lies is, again, much less of an issue if you boot from a known-clean CD rather than using it from the running compromised installation

You can't trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.

Again, once all that might be compromised is data, there's nothing there to tell lies to the antivirus software. A text file isn't going to somehow run executable code when you open it in notepad. (whether "untrustworthy data" is an issue depends on what kind of data it is and, for that matter, what kind of attack - that shiny new browser toolbar might be nasty, but it isn't likely to be all like "im in ur spreadsheets messin with ur numbers" - for that matter, the worst a virus is likely to do is destroy data in obvious ways, not mess with it in a way that you won't notice and will cause problems if you rely on it later. The article seems to be geared towards cases of actual human attackers, not virus/spyware/etc)

Re:Arms race for nothing (0)

Anonymous Coward | more than 7 years ago | (#19878491)

> Fdisk it from orbit - it's the only way to be sure.

That is a great fsking line! I'm stealing it, and turning it into a meme!

Would you like a credit, or just annon ?

Thanks!

btw- if you search for it in google you find it here... How often is google updating their bloody slashdot index!?

Re:Arms race for nothing (1)

Saurian_Overlord (983144) | more than 7 years ago | (#19873387)

If more people could self-police their PC like me, it would put a dent in both the virus and anti-virus businesses and as a result, it would slow the evolution of malware.

Yeah, I did things that way for a long time myself. It's gotten to the point, however, at which things I trusted in the past are becoming littered with infectious software. I had no problems for years until fairly recently.

If two kids are fighting over a silly toy, when you take away the toy, they find something else to occupy them. Virus authors are no different.

By that logic, if we all "self-police" our PCs and "slow the evolution" of malicious programs as you predict, then the "virus authors" will simply find another way of doing things. Perhaps they'd focus their attention on more legitimate-looking fronts. Then even more people would be forced to run software for fear of a virus imitating or hijacking something like a device driver or a critical Windows update.

Anyway, call me paranoid, but I've long suspected that the anti-virus companies themselves are the ones releasing the malicious code, or at least exposing known security flaws (we already know that happens within other companies), so I doubt it would make a difference either way.

cat /dev/colon /proc/virtual/1 (1)

eknagy (1056622) | more than 7 years ago | (#19873789)

Ha!

I always know there are security problems with sandboxes - and all the cats on the world surely know how to break them:
cat /dev/colon >/proc/virtual/1

Who cares if it can detect a virtual machine? (0)

Anonymous Coward | more than 7 years ago | (#19874817)

Isn't it awful that a VMware virtual machine has its own VMware specific registry entries, drivers, services that make it so obvious the system is virtual? NO!!! Who cares! If a hacker can get at your registry or list drivers, they don't need to attack the hypervisor. Give them a bit and (assuming your VM is on the network) they'll be running through your network without going through the hypervisor.

I have not worked much with other virtualization technologies but if I wanted to attack a VMware virtual infrastructure (and I don't), IMO the weakest link is the VirtualCenter server. It communicates with each VMware Host (ESX, Virtual Server) and controls resource allocation (memory, network, CPU, disk shares), network connectivity through the host, virtual machine power functions, etc. of the entire virtual environment. And hey, it runs on Windows, a hacker's favorite target. Why would a hacker waist time learning how to hack into the hypervisor (rhetorical.. I know the answer... Because it's there...) when he already know how to hack into the one box with the keys to the virtual kingdom. Sure the hypervisor is an attack vector, but there are bigger, more probable ones that would concern me first!

Protect your VirtualCenter server folks. It is the weakest link.

Centipedes? (1)

Wiseman1024 (993899) | more than 7 years ago | (#19875177)

In MY sandbox?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?