Saw it on wilders. LeakOut
Proactive, FW Safe Mode, D+ Safe Mode, Sandbox enabled.
Ran the test, Sandboxed and hit OK.
No alerts and a web page shows my user name, computer name and windows installation folder.
Nice one. :o
[attachment deleted by admin]
I can confirm this. If the sandbox is disabled CIS blocks it, but with the Sandbox enabled it is sandboxed and then able to open and display my information in a Firefox tab. There are no alerts.
This program doesn’t seem to work with Comodo Dragon. I had to switch my default browser to Firefox before it would start.
I’m running Windows 7 x64 and my settings are the same as for burebista. I do have the button to ‘Automatically detect installers/updaters and run them outside the Sandbox’ unchecked.
The more leaktests like this people find the better the sandbox will become. This information should not be able to be accessed and sent from within the sandbox. Devs, here’s another one.
it does work with dragon on my comp. With sandbox off you get one execution alert, then alert saying leakout is executing dragon, allowing both shows the info in the browser.
It works with Dragon if Dragon is already running. If Dragon is not running, it will be sandboxed, and then it doesn’t work.
Shows Machine Name and User Name, but not Windows Directory on my system (XP SP3, Dragon).
Just to check, so you (plural!) are saying:
[ol]- Leakout.exe is sandboxed
- LeakOut acquires the information from the PC
- Leakout executes the browser on the same machine, causing it to access an external url, which returns a form, which the bowser fills in. This is done without accessing the browser in memory or using protected COM interfaces. (How is it done? Via CMD?)
- information includes the user name used to log on to Windows
- Leakout directly executes the browser on the same machine, causing it to access an external url, which returns a form, which the bowser locally fills in
- This works because the browser is normally allowed outbound access without alerts (of course)
- So the concern is that the browser could have continued to execute a post action at the remote site
- So this is a design flaw (not a bug) as the Sandbox is operating as specified in the help file. (Sandboxed files can execute others. [/ol]
Do I have this right?
Seems right to me. It opens the browser and fills in the data. It also receives the location of the Windows Directory.
Either way it is a large vulnerability that needs to be fixed.
Edit: I performed this test with Firefox as the default browser.
From my own testing the leakout PoC succeeds only with certain web browsers when it is Sandboxed:
Internet Explorer 8 - not affected
Opera 10.53 - not affected
Comodo Dragon 184.108.40.206 - affected only if it was already opened
Google Chrome 5.0.375.55 - affected only if it was already opened
Safari 4.0.5 - affected only if it was closed before
Firefox 3.6.4 - fully affected (fails when it was already opened or closed before)
Tested on VM Windows XP Pro x86.
Edit: Added Safari and Google Chrome to the list.
Looks like the the info are filled right into the URL that is passed as a commandline parameter to the default browser (section 3 of anubis report)
Guess this could be considered equivalent:
echo PC name: %computername%
echo User: %username%
echo Windir: %windir%
echo How many more?
start %windir% %username% %computername% - Google Search
Not sure how large or how serious it is.
Guess for the info gathering part a lot of environment variables comes to mind.
Not sure if all of them are supposed to be blocked. ???
BTW CLT DDE and OLE automation tests are similar in purpose (start clt.exe)
I have reported this to the Dev, so it should be looked at soon.
Many thanks to everyone who raised this and checked this out.
More a design issue than a bug, but no where obvious to post it, as its not quite a wish list item either.
So I’ll leave it to the devs to ask if they want system details.