ZeroFill, a good idea?

On Tue, 22 Jan 2013 09:46:01 +0000, amarildojr wrote:

> My concearn is if I re-install the system, re-install Wine and the same
> process access the same file on the folder I’ll be infected again.

That can not happen. If you reinstall the system, there’s no pointer to
the file data - and a virus (by its nature) is minimal code (usually with
no error handling). Directory structures aren’t consistent enough to
access files from a previously accessed system using a newly installed
system.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On Tue, 22 Jan 2013 17:56:02 +0000, deano ferrari wrote:

> Yes, but in general we’re talking about user-space files, and not a
> virus that may be resident in memory. The question was being asked as to
> whether deleting a virus was sufficient, as opposed to overwriting with
> zeroes…

Well, certainly, through WINE there’s less chance of direct access to
specific disk blocks.

But I’m thinking that things like Windows-based file recovery tools
(which access the disk directly to read the Directory Entry Tables and
other critical areas of the disk) wouldn’t work because the filesystem
isn’t FAT/FAT32/NTFS, so the tables aren’t actually there.

Zeroing the file would be unnecessary - but I’d go a step further and
question why one would connect to a server knowing it has a virus on it,
rather than notifying the operator that they’re spreading a virus.

But one must also remember that in *nix, you can delete files that are
open, so if the code is executing in memory (as an executed file),
deleting the file isn’t sufficient, either. You have to make sure the
process is dead first.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

you could always try openSUSE +apparmor(VM(WINDOWS+games))

On 2013-01-22 18:56, deano ferrari wrote:
> Yes, but in general we’re talking about user-space files, and not a
> virus that may be resident in memory. The question was being asked as to
> whether deleting a virus was sufficient, as opposed to overwriting with
> zeroes…

But can a Windows process be resident in memory, in Linux via wine? Once
wine exits, those processes, if there, can no longer run, there is no
Windows api to talk to. Unless those libraries remain loaded, too. I’m
speculating, I don’t know much about those Wine details: I don’t know if
once Wine exits all its libraries are unloaded or some can remain.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On 2013-01-22 19:26, vazhavandan wrote:
>
> you could always try openSUSE +apparmor(VM(WINDOWS+games))

Yes, with AA you can impede code from writing outside of the wine directory.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On Tue, 22 Jan 2013 18:44:06 +0000, Carlos E. R. wrote:

> On 2013-01-22 18:56, deano ferrari wrote:
>> Yes, but in general we’re talking about user-space files, and not a
>> virus that may be resident in memory. The question was being asked as
>> to whether deleting a virus was sufficient, as opposed to overwriting
>> with zeroes…
>
> But can a Windows process be resident in memory, in Linux via wine? Once
> wine exits, those processes, if there, can no longer run, there is no
> Windows api to talk to. Unless those libraries remain loaded, too. I’m
> speculating, I don’t know much about those Wine details: I don’t know if
> once Wine exits all its libraries are unloaded or some can remain.

I’ve observed that exiting programs started by WINE doesn’t always shut
WINE down - so presumably if a background process continues running,
it’ll keep running even if the application that started it has terminated
without killing that process.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2013-01-22 22:00, Jim Henderson wrote:
>> > But can a Windows process be resident in memory, in Linux via wine? Once
>> > wine exits, those processes, if there, can no longer run, there is no
>> > Windows api to talk to. Unless those libraries remain loaded, too. I’m
>> > speculating, I don’t know much about those Wine details: I don’t know if
>> > once Wine exits all its libraries are unloaded or some can remain.

> I’ve observed that exiting programs started by WINE doesn’t always shut
> WINE down - so presumably if a background process continues running,
> it’ll keep running even if the application that started it has terminated
> without killing that process.

Although I have used wine now and then, I don’t remember the details. If
wine continues running in those cases, it is then easy to see that it is
running, so closing the window should kill any resident code.

I don’t know if I explained myself :-?


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On Tue, 22 Jan 2013 21:14:06 +0000, Carlos E. R. wrote:

> On 2013-01-22 22:00, Jim Henderson wrote:
>>> > But can a Windows process be resident in memory, in Linux via wine?
>>> > Once wine exits, those processes, if there, can no longer run, there
>>> > is no Windows api to talk to. Unless those libraries remain loaded,
>>> > too. I’m speculating, I don’t know much about those Wine details: I
>>> > don’t know if once Wine exits all its libraries are unloaded or some
>>> > can remain.
>
>> I’ve observed that exiting programs started by WINE doesn’t always shut
>> WINE down - so presumably if a background process continues running,
>> it’ll keep running even if the application that started it has
>> terminated without killing that process.
>
> Although I have used wine now and then, I don’t remember the details. If
> wine continues running in those cases, it is then easy to see that it is
> running, so closing the window should kill any resident code.
>
> I don’t know if I explained myself :-?

Closing the window doesn’t kill background processes that the program
that creates the UI starts. Windows can fork background processes, too,
and those processes don’t have to have a UI associated with them.

That would particularly be the case with a virus that implicitly runs in
the background as a “hidden” process.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2013-01-22 22:26, Jim Henderson wrote:
> On Tue, 22 Jan 2013 21:14:06 +0000, Carlos E. R. wrote:

>> Although I have used wine now and then, I don’t remember the details. If
>> wine continues running in those cases, it is then easy to see that it is
>> running, so closing the window should kill any resident code.
>>
>> I don’t know if I explained myself :-?
>
> Closing the window doesn’t kill background processes that the program
> that creates the UI starts. Windows can fork background processes, too,
> and those processes don’t have to have a UI associated with them.

But can those forked processes run out of the control of the Wine window
that hosts them initially?

Remember that those processes can not interact with Linux directly.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On Tue, 22 Jan 2013 23:54:07 +0000, Carlos E. R. wrote:

> But can those forked processes run out of the control of the Wine window
> that hosts them initially?

There is no “WINE window”. Yes, those forked processes can continue if
the application is shut down. I’ve seen it happen on WINE and Crossover
(which uses WINE) and have had to use the Crossover tools to actually
kill the WINE session.

> Remember that those processes can not interact with Linux directly.

Of course they can’t. But if a Windows process is still running, then
WINE keeps running.

WINE isn’t a perfect sandbox, mind, but it’s pretty good. But if a
Windows process forks something, WINE knows about it and keeps running.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

  • A question was whether deleting a file really deletes the file. Under normal circumstances, no and the file can be recovered <until that location on the disk is over-written>. And, that is the presumed logic behind zeroing empty space, obliterating any latent files which only need to be recovered to become potentially active again. If the disk is very full (ie >80% full with plenty of regular writes), then over-writing will likely happen naturally without waiting too long, but if you really want to be sure you should zero the space.

  • Is zeroing actually necessary? Probably not. Although I may not have heard of it, I have never heard of an exploit rummaging through trash and recovering deleted files.

  • Zeroing in preparation for a new install? - Probably reformatting maybe even a couple times would likely be more efficient although zeroing might do a better job.

  • Exploits running in Wine - Well, I’ve seen exploits that intentionally install *NIX filesystems on Windows systems as one way to root the system… which means… The process is actually running *NIX functions that could potentially damage your Linux system!

  • Ounce of Prevention better than a Pound of Cure… Sandbox your risky activities. If you already know that Gaming exposes your system, then run virtualized or on a separate HDD. I don’t know that simply logging in with a different User might be sufficient… but maybe if your game runs in Wine it would not require access outside of the /home directory. YMMV, take a look at what is happening on your system and of course this means <no shared directories or drives> between Users, and of course nothing running with elevated permissions.

IMO,
TSU

I believe you can stop wine processes by running wineserver -k

On 2013-01-23 01:52, Jim Henderson wrote:
> On Tue, 22 Jan 2013 23:54:07 +0000, Carlos E. R. wrote:
>
>> But can those forked processes run out of the control of the Wine window
>> that hosts them initially?
>
> There is no “WINE window”. Yes, those forked processes can continue if
> the application is shut down. I’ve seen it happen on WINE and Crossover
> (which uses WINE) and have had to use the Crossover tools to actually
> kill the WINE session.

That was my doubt. Ok, then I worry.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On 2013-01-23 02:36, nightwishfan wrote:
>
> I believe you can stop wine processes by running wineserver -k

There are two ways of using wine. One is running native Windows programs
under the Wine emulator.

Another is running a Linux native program which instead makes calls to
wine libraries. It is a Windows program that has been ported to Linux,
but making library calls to an API equivalent to Windows. That is, most
of the original source code of the program is kept, it makes it Windows
like calls to an API that translates them to Linux calls. The main
difference is that the code is really a Linux executable.

It can also be used by developers that are not used to Linux, so that
they can use Linux programs with the methods and libraries they are
accustomed to use in Windows. Like using the GTK or QT toolkits, but
instead it is the Wine toolkit.

For example, the Delphi 1 for Linux made by Borland was ported this way.

Such a program is fully a Linux program, and should not be vulnerable to
Windows viruses. It is not an .exe.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On Wed, 23 Jan 2013 01:36:01 +0000, nightwishfan wrote:

> I believe you can stop wine processes by running wineserver -k

That is true. Since I own Crossover, I tend to use cxpm. :slight_smile:

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On Wed, 23 Jan 2013 01:36:01 +0000, tsu2 wrote:

> - Zeroing in preparation for a new install? - Probably reformatting
> maybe even a couple times would likely be more efficient although
> zeroing might do a better job.

If the purpose is just to render the drive unreadable, then zeroing won’t
defeat advanced recovery tools (out-of-band tools, here, not something
that runs on the machine). Multiple passes with /dev/urandom rather
than /dev/zero is generally considered the most secure way to wipe a
drive.

Or do what I do with an external drive - full disk encryption, with keys
off the drive. Since I’ve had a couple external USB drives go poof with
sensitive data on them, I’ve started encrypting those drives so if I opt
to return the drive (if it dies within warranty), the drive is
unrecoverable using forensic tools.

> - Exploits running in Wine - Well, I’ve seen exploits that intentionally
> install *NIX filesystems on Windows systems as one way to root the
> system… which means… The process is actually running *NIX functions
> that could potentially damage your Linux system!

Well, exploits written for Windows that “install” a *nix filesystem
(which I’ve never heard of before) would use Win32 libraries, so it would
be passed through WINE, so not using native *nix libraries.

> - Ounce of Prevention better than a Pound of Cure… Sandbox your risky
> activities. If you already know that Gaming exposes your system, then
> run virtualized or on a separate HDD. I don’t know that simply logging
> in with a different User might be sufficient… but maybe if your game
> runs in Wine it would not require access outside of the /home directory.
> YMMV, take a look at what is happening on your system and of course this
> means <no shared directories or drives> between Users, and of course
> nothing running with elevated permissions.

For a normal user (and you hint at this), only /home/username and /tmp
would be writable in normal conditions, and /home/user1 wouldn’t be
accessible, so that would generally be sandboxed enough, unless you allow
the sandboxed user to use sudo without a password (for instance) - which
would defeat the sandboxing anyways.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

So by creating a new user profile will fix any infection ?
Also is there any way to disinfect some of files from user(infected) from user1 login using clamav or something and recover those files?

On Mon, 28 Jan 2013 06:06:01 +0000, vazhavandan wrote:

> hendersj;2521205 Wrote:
>> On Wed, 23 Jan 2013 01:36:01 +0000, tsu2 wrote:
>>
>> For a normal user (and you hint at this), only /home/username and /tmp
>> would be writable in normal conditions, and /home/user1 wouldn’t be
>> accessible, so that would generally be sandboxed enough, unless you
>> allow the sandboxed user to use sudo without a password (for instance)
>> - which would defeat the sandboxing anyways.
>>
>> Jim
>>
>> –
>> Jim Henderson openSUSE Forums Administrator Forum Use Terms &
>> Conditions at http://tinyurl.com/openSUSE-T-C
>
> So by creating a new user profile will fix any infection ?

The purpose isn’t to fix an infected file. It’s to limit the spread of
an infected file.

If a virus is running under WINE and you log out (thus terminating the
WINE instance), then the infected file can’t affect anything else by
virtue of not being in memory being executed by WINE any more.

If an infected file were in /tmp, that /could/ cause it to spread if the
file in /tmp/ were executed and WINE started up to infect it. You’d have
to almost be trying to cause that to happen, though.

> Also is there any way to disinfect some of files from user(infected)
> from user1 login using clamav or something and recover those files?

Sure. You could even do that as user1 (which would be best IMHO).

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

This thread seems to be about the hypothetical, and for the ultra paranoid, But hey, it makes for a good read;).

Oops. Here is the deal. I loaded an infected flash drive on my machine(read signature)
I saw a file Autorun.ini in the flash drive and i openened in Gedit and saw that it was referring to an exe file inside a folder inside the flash drive.
I immediately understood that this means a bad omen.
I did a ctrl+del(the new nautilus thing) by manner of habit.
When i ejected the drive using nautilus it was giving a busy warning and when i re-inserted the flash drive again i could see that the ini as well as the folder with the exe had gotten restored.Then i tried Shift+del and then it did not reappear again.
How did the virus / malware files get restored ?
Were they somehow able to execute on my Linux ?
I was running banshee when this happened. Did the mono stuff cause this issue.
I know that i am equating things in a bizarre fashion. Kindly advice. Thanks