Jesse Pollard wrote:
> Ummm maybe. A SANS newsletter indicated that none of the current virus scanners
> even look at the other data streams (yet).
I attribute that to MS not showing data streams, er, I just call them forks, in
Explorer. If users were more aware of forks, and could manipulate them, virus
scanners would be on top of it as well.
> Determining if the default stream
> is actually infected could be problematical too - consider that the signature
> of the virus might be a VERY short piece of code that looks just like other
> pieces that do ligitimate functions (like start another process...). This could
> give many false positives, making a scan nearly useless.
Yes, it does present cool (from a virus writer's pov) opportunities for hiding
data/code, but you could do a similar thing with a regular file system, using
multiple files instead of forks in a single file. The code is the same for opening
forks vs. regular files, its just that the forks are (currently) hidden from users.
However, this whole thing is about how a virus hides itself on a host. It has to
get there first, and forks aren't gonna help it do that, except, I guess, if you
recieved binary software on NTFS formatted zip disks or something like that, but
that can't be very common.
>
> The current NT utilities also have a problem in that a stream could consume
> the entire disk, but not be visible to the standard utilities - they don't
> list file size of any but the default stream.
Yeah, again, MS being dumb about Explorer.
>
>
> Of an interesting note: one of the suggested fixes involved copying the
> infected file to a "non windows system such as Linux..." (paraphrased.. not
> real quote) and then copying it back without the alternate stream(s).
>
>
I only read portions of the net-security notice. Probably copying it to a FAT
drive under NT will do the same thing. If you copy, via Explorer, a file with some
forks to a FAT drive, Explore will pop up a little warning telling you that you are
going to lose some data.
The other nefarious use of forks is for hiding data, ie. your p0rn collection, or
the real version of your financial books that you don't want the IRS to see.
The whole argument a few weeks back on l-k about how to shoehorn forks into the
current "way things work" was kinda disapointing. I almost jumped in, but I
chickened out.
I was waiting for someone to notice the really nice equivalence between a file
system with forks like NTFS, and directories like X.500/LDAP.
Basically, you've got:
leaf objects equate to files
branch objects equate to directories
Directory objects have attributes (ie. objecttype=top, surname=Ford,
phonenumber=1234567, etc).
In a file system, files and directories can have forks (ie. forkname "objecttype",
stream stores "top").
Branch objects in a directory can have children.
Directories in a file system can have children.
The metaphor probably breaks down at some level, but it's still pretty cool.
I have no idea if its even a good idea to have a file system be more like a
directory, but I just couldn't help seeing the similarity and thinking, gee, what
if...
-Trevor
ps. My apologies to to Keith Owens for being a little short tempered in my reply.
But, yelling the sky is falling because of some anti-virus vendor's vague warning
about something as lovely and innocent and unsullied as file system forks just
makes me <pressing palm against side to head to make the voices be
quiet>maaad</pressing....> :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:29 EST