Using Internet Explorer on Kubuntu

[molostoff]

Re: Using Internet Explorer on Kubuntu

WINE is not Windows.
...
So, here are the answers to your two questions;

• No WINE does not compromise your systems security
• No, IE7 and IE8 cannot be successfully installed and run on Linux, even in WINE

I consider, definitely. WINE does (and can do) compromise user space security (actions permit to a linux user running wine), BUT not system (in opposite to windows, where IE activx can modify their system). So (1) it indeed does not compromise your systems security.

For a second, I agree that opening and displaying an html page is not all the work a good browser does - there are much things with https, keys & certificates, also an access to shared embedded objects (word documents or pdf?), scripting of .net and so on - so the verdict for this is an unbelievable to see IE fully workable under wine, even just displaying html page.

[GreyGeek]

Re: Using Internet Explorer on Kubuntu

....
I'm sorry - but I'm afraid that you're wrong. Read what is written in the Wine FAQ, specifically on http://wiki.winehq.org/FAQ#head-1c91...2be4f346eebe87. You're assertion that nothing outside the Wine environment can be accessed is not true unless you delete the z: drive.

He said:

Anything running in WINE cannot access anything outside of this runtime environment directly, would not understand the file structure if it could, and also would not have any permissions to do anything.
There have been attempts to get viruses and malware to run in WINE, but without success. The WINE crew has taken known working examples and tried to execute them in the WINE environment and they still did not work.
In any case, even if something were to become infected the cleanup is as simple as deleting the WINE folder with its Windows file structure that is contained therein.
The short answer to the security question is therefore; No, running Windows programs in WINE does not expose the rest of the system to Windows security "issues."

The link you cite says:

Consider removing the default Wine Z: drive, which maps to the unix root directory. This is only a weak defense, but it might help against some attacks. The downside to this is you won't be able to run Windows applications that aren't reachable from a Wine drive (like C: or D. This includes inability to install Wine-gecko (see bug 19873). A work around is to copy/move/symlink downloaded installers to ~/.wine/drive_c before you can run them.

The "weak defense" is moving Windows executables out of your Linux paths and into the virtual hard drives, "C:" & "D:", etc., that WINE creates. But the question remains "defense against what?"

Every Windows malware that I have tested in WINE has worked, with the exception of keyboard loggers residing in the MBR because there is no MBR on the WINE "C:" drive, and, it is never "booted". It is merely the name of a file to Linux. Once the infection delivers its payload an autopsy can be performed on the "C:" drive and the WINE memory space to see what was left behind. After the autopsy, the usual tactic is to entirely uninstall WINE and its drive emulations, then reinstall it. I never had any success in getting supposedly "cross platform" Windows jpg malware to execute in Linux.

The "Z:" drive is mapped to your Linux home account and any Windows executables residing in your home account can be executed by WINE but that doesn't give that executable any special capability because it is still running within the WINE environment and only sees the memory WINE uses and the drive mappings WINE created. The only directories it could destroy with Windows commands are those created by WINE to emulate the C, D & Z and other similarly mapped "HD"s. Even UNC commands (\\computer_name\share_name) called by Windows applications running in WINE work only in the WINE drive space. In Linux, IF you had SMB installed you'd use smb://computer_name/share_name.

Windows executables are determined by extensions, which are EXE's (& COMs) and BAT files, which contain valid DOS commands. They can be on the HD or in an email or part of memory space and still execute. A DOS name can have many extensions. The first one is reported as the file type by Windows but the LAST one is called by DOS to determine executability. DOS commands have their own kernel entry points (like int 0x21) and parameters to pass. Linux executables are ELF binaries bash shell commands, and scripts containing bash shell commands. They can be executed ONLY if they are residing on the HD, and then only if that execute permission is set for the user trying to execute the executable. They all must communicate through libc6 (consult cat /var/lib/dpkg/info/libc6.list) to the Linux kernel, but bash commands and shell scripts can do that ONLY if they include the "!#/bin/bash" as their first line, AND ONLY if their execute permission set. And, each of the libc6 libraries have their own parameter lists, types and orders. A Windows call to a DOS kernel entry point would fail under Linux. The primary purpose of the Z: drive is to afford an easy way to move data files between Linux and WINE, but Dolphin can navigate ~/.wine/../c_drive as easy as any other directory so Z: isn't really needed. A Windows command attempting to call a Linux executable could only do so for executables residing on the "Z:" drive, hence the suggestion to delete the "Z:" drive. But, what could a Windows (WINE) environment do when it called a Linux executable on the Z: and that executable tried to call /lib/libc-2.11.1.so ? It doesn't know how to handle "/" except as a parameter switch or part of the UNC command structure. It only knows C:, D:, Z: in its PATH statement, and adding a Linux path to the WINE PATH variable won't help.

Finally, we have experience to look at. In 12 years of using Linux I have never heard or read of a Linux installation being compromised or destroyed by a Windows malware running inside of WINE. We are all aware of Windows notorious vulnerability. Linux & FOS own 70% of the Internet servers, a large percentage of corporate servers, and over 10% of the US desktop market share (more in some other countries). IF Linux were susceptible to such an attack route we'd be reading about it and giant Linux bot farms in the media. Microsoft and Apple would make sure of that.

Here is a recent classic example of someone trying to infect their Linux box using a Windows virus in WINE: http://blog.opensourcenerd.com/i-can-haz-virus

And here is a humorous tale of how to infect your Linux box with a virus: http://www.gnu.org/fun/jokes/evilmalware.html

But, IF you really WANT to get your Linux installation infected the easiest way to do so is to install a deb package or tar ball from an unvetted source. To do that you will have to download the file. Run
sudo dpkg -i packagename
or untar it and cd into the source cod directory, run "./configure", "make" and "sudo make install".
There. Your infected. I don't know of an easier way to do it, which makes nonsense out of the statements often made by some that Linux is as easy to infect as Windows.

[skunk]

Re: Using Internet Explorer on Kubuntu

You can install IE7 and IE8 using winetricks
http://wiki.winehq.org/winetricks

[skunk]

Re: Using Internet Explorer on Kubuntu

You can also easily bork a working wine configuration using winetricks, so be extra sure to use a dedicated WINEPREFIX if you try

[Detonate]

Re: Using Internet Explorer on Kubuntu

I feel a little smug about all of this. I don't use wine. I don't need anything wine provides. I do have Windows XP in a virtual machine. I boot it up once a month to run the updates. I only have it because I take care of a bunch of computers for other people and I sometimes need it for a reference. Getting to the point where I will soon have to get W7 and run it also in a virtual machine for the same reason. Other than that, I have no need for Windows or any windows programs. If I can't do it in linux, I don't do it.

[molostoff]

Re: Using Internet Explorer on Kubuntu

You can install IE7 and IE8 using winetricks
http://wiki.winehq.org/winetricks

Looks capitally. I'll take it into my windows account.

[tlu]

Re: Using Internet Explorer on Kubuntu

The "weak defense" is moving Windows executables out of your Linux paths and into the virtual hard drives, "C:" & "D:", etc., that WINE creates. But the question remains "defense against what?"

Every Windows malware that I have tested in WINE has worked, with the exception of keyboard loggers residing in the MBR because there is no MBR on the WINE "C:" drive, and, it is never "booted". It is merely the name of a file to Linux. Once the infection delivers its payload an autopsy can be performed on the "C:" drive and the WINE memory space to see what was left behind. After the autopsy, the usual tactic is to entirely uninstall WINE and its drive emulations, then reinstall it. I never had any success in getting supposedly "cross platform" Windows jpg malware to execute in Linux.

The "Z:" drive is mapped to your Linux home account and any Windows executables residing in your home account can be executed by WINE but that doesn't give that executable any special capability because it is still running within the WINE environment and only sees the memory WINE uses and the drive mappings WINE created. The only directories it could destroy with Windows commands are those created by WINE to emulate the C, D & Z and other similarly mapped "HD"s.

I don't think that's correct. I was able to install a windows app in my home directory outside of .wine. And if you simply start, e.g., the Windows editor from Wine it can save a file anywhere in your home directory. That means that generally any Windows applications could also delete important data/settings in your home directory. Now I admit that I manually chose these target directories outside of .wine in the "save" window, and yes - most Windows malware would not be aware of them. But would you really rely on that? The probability is very low for sure, but in the case of "intelligent" malware it's certainly not zero.

[jpenguin]

Re: Using Internet Explorer on Kubuntu

... a terrible web browser running in a windows emulator.

Tell me you didn't call WINE an emulator


I don't know why you would want to run MSIE on linux, but I would suggest winetricks or CrossOver Office

[GreyGeek]

Re: Using Internet Explorer on Kubuntu

.....
The "Z:" drive is mapped to your Linux home account and any Windows executables residing in your home account can be executed by WINE but that doesn't give that executable any special capability because it is still running within the WINE environment and only sees the memory WINE uses and the drive mappings WINE created. The only directories it could destroy with Windows commands are those created by WINE to emulate the C, D & Z and other similarly mapped "HD"s.

I don't think that's correct. I was able to install a windows app in my home directory outside of .wine. And if you simply start, e.g., the Windows editor from Wine it can save a file anywhere in your home directory. That means that generally any Windows applications could also delete important data/settings in your home directory. Now I admit that I manually chose these target directories outside of .wine in the "save" window, and yes - most Windows malware would not be aware of them. But would you really rely on that? The probability is very low for sure, but in the case of "intelligent" malware it's certainly not zero.

IF you were using WINE then your program was installed on the Z: drive. When not running WINE your program sets in your ~/ directory as if it were a Linux program. But, when you execute it from the menu the WINE mime fires WINE, which creates the "Windows" environment in which the Windows program runs. IF the program used "rmdir -s Z:" then the entire Z: directory would be deleted, i.e., your home account, but that is about all it could do. IF there were any files in your home account not owned by you they would prevent the "rmdir" command from deleting the directory tree in which those files exist. That's why it is a good idea to back up files in your home account.

There is no such thing as "intelligent" software. Software is not a conscience entity. It can do only what it has been programmed to do. Even "fuzzy" logic and Neural Nets are not "intelligent". Without escalation to root the only rights malware has are those of the user who installed it, since malware generally cannot install itself in Linux without the users help. What you probably meant to say was that an intelligent programmer might be able to embed code in a harmless looking application which can exploit some existing security hole known only to bad guys and elevate its permissions to root level. The odds of that happening are certainly not zero, but they also are not significant either, or such activities would be a common occurrence by now, and Linux malware numbers would exist in proportion to its market share, as would the size of Linux bot farms. IIRC, the current count for Windows malware EXISTING IN THE WILD for THIS year is around 2.3 million. I don't know of any Linux malware current wreaking havoc among Linux users. The largest Linux malware (Slapper) infection occurred at about the same time as the Windows CodeRed was infecting millions of Windows boxes. Slapper infected about 25,000 boxes in Eastern Europe, which were running a version of Linux which installed the user as root. Bad move. Currently, the largest Windows bot farm discovered so far contained 1,300,000 Windows zombies, all harvested by automatic email mailings. The largest Linux bot farm discovered so far had about 700 Linux zombies, and it took the hackers over six months to accumulate that farm because they had to resort to a form of war driving and "dear john" password cracking, a slow process.

Wise Linux users have rkhunter and chkrootkit installed and they are run by cron on a regular basis. IF any of your files where changed or unauthorized new ones were installed they would be notified.