Prev: Fixing a problem for a friend
Next: Automatic Renewal ZoneAlarm
From: FromTheRafters on 18 Jan 2010 08:34
"Dustin Cook" <bughunter.dustin(a)gmail.com> wrote in message
news:Xns9D02121AB16ACHHI2948AJD832(a)69.16.185.250...
> http://www.itworld.com/security/90249/ignore-microsoft-check-everything?
> source=peer2peerpromo

I think that the *experts* need to re-read the article and assume (for
the most part) that the language is concise (generally a dangerous
assumption these days, the English language is being eroded by users
that don't care about what words mean - mere semantics, they say).

They do *not* recommend excluding by extension. In fact they explicitly
state that point many times. The wildcard characters are there to
indicate that more than one file targeted for exclusion (ending in
'.log') may be there. It seems to me that any malware.log file added
after implementing the exclusions would *not* be excluded, and that
replacing an extant file with malware by the same name would just
manifest as corrupt data.

Did these *experts* even read the article that they blather on about?

I agree, however, that the general public could get into trouble by
misinterpreting this list.

A thought just occurred to me (hold the applause) - what would happen if
I replaced the "hosts" file with an OLE2 malware file? Would the browser
find corrupt lookup data or would the damned thing execute? :o)

IIRC OLE2 files can invoke Word and embedded macro malware could execute
even with no filename extension to associate it. IOW it is the actual
file format that gives the association - and the "hosts" file is
extensionless.




From: Ant on 18 Jan 2010 12:22
"FromTheRafters" wrote:

> "Ant" wrote:
>> [wmf]
>
> What I meant is that an attacker using this filetype for hostile code is
> not exploiting a software vulnerability in this case, but is abusing a
> function. That function was deprecated and nearly forgotten, and the
> filetype was assumed to be graphic data only.

Yes, it was by design and deprecated in Win 3.1 as I recall from reading
the SDK docs of that OS when I did some investigation of it!

>>[ms kb]
>
> Did you see any reference to excluding an entire folder? Or was that
> reference intended to mean all files within that folder that were placed
> there by the OS installation?
>
> I think that they might have meant that all files placed (by default by
> the OS when installed) within some folders and only *some* files
> (identified by filename or extension) in other folders.

The article is in three parts, and the first is very specific about
which files to exclude apart from some wildcarded files, e.g. '.log'
in %windir%\security. However, it does stress the importance of
edb.log and edb.chk. Now suppose some malware dropped an exe called
abc123.log in there and ran it from a 'hk..\...\run' registry key?
I would say you'd have to know exactly the names of the '.log', etc.
files which are are supposed to be there, depending on your system
and configuration, and exclude only those.

The second and third parts are for servers and domain controllers and
they do mention complete directories, namely:
%systemroot%\sysvol (and some of its subdirs)
%systemroot%\system32\dns
%systemroot%\system32\wins

I'm wondering if the article is aimed mainly at system administrators
and perhaps AV vendors. I can't see the average user being able to
deal with all this.


From: Ant on 18 Jan 2010 12:24
"FromTheRafters" wrote:

> A thought just occurred to me (hold the applause) - what would happen if
> I replaced the "hosts" file with an OLE2 malware file? Would the browser
> find corrupt lookup data or would the damned thing execute? :o)

The hosts file is not directly accessed by browsers but by the handful
of DLLs that implement domain name resolution and sockets.

I can say that dnsrslvr.dll (DNS Caching Resolver Service) and
rnr20.dll (Windows Socket2 NameSpace) treat it as a plain-text file,
using the standard C runtime routines fopen and fgets to read the
contents. No danger of OLE interfering.


From: FromTheRafters on 18 Jan 2010 13:35
"Ant" <not(a)home.today> wrote in message
news:0I2dnTlO4cLABMnWnZ2dnUVZ8tudnZ2d(a)brightview.co.uk...
> "FromTheRafters" wrote:
>
>> "Ant" wrote:
>>> [wmf]
>>
>> What I meant is that an attacker using this filetype for hostile code
>> is
>> not exploiting a software vulnerability in this case, but is abusing
>> a
>> function. That function was deprecated and nearly forgotten, and the
>> filetype was assumed to be graphic data only.
>
> Yes, it was by design and deprecated in Win 3.1 as I recall from
> reading
> the SDK docs of that OS when I did some investigation of it!
>
>>>[ms kb]
>>
>> Did you see any reference to excluding an entire folder? Or was that
>> reference intended to mean all files within that folder that were
>> placed
>> there by the OS installation?
>>
>> I think that they might have meant that all files placed (by default
>> by
>> the OS when installed) within some folders and only *some* files
>> (identified by filename or extension) in other folders.
>
> The article is in three parts, and the first is very specific about
> which files to exclude apart from some wildcarded files, e.g. '.log'
> in %windir%\security. However, it does stress the importance of
> edb.log and edb.chk. Now suppose some malware dropped an exe called
> abc123.log in there and ran it from a 'hk..\...\run' registry key?

It would presumedly be scanned, as it wasn't one of the mentioned files
to be specifically excluded. The wildcard just means that there are
various files to be excluded based on that wildcard naming, not that all
future files fitting that wildcard naming are automatically excluded.

Placing a malware file in there and making it run from the registry is
not a virus infection, it is a trojan. I don't think they are trying to
exclude non-viral malware from scanning. They state only that the files
are not infectable.

> I would say you'd have to know exactly the names of the '.log', etc.
> files which are are supposed to be there, depending on your system
> and configuration, and exclude only those.

I think that is the point that they are trying to make. This is
configuration option suggestions for a new installation.

> The second and third parts are for servers and domain controllers and
> they do mention complete directories, namely:
> %systemroot%\sysvol (and some of its subdirs)
> %systemroot%\system32\dns
> %systemroot%\system32\wins

Yeah, I fear that they depend on those always having handles open (while
the service is running) and again cannot be infectable. This part
worries me, cannot a service be interrupted - and then the infection
made? Anyway, if there is only data in there, there can be no infection.
Trojans are another story. I'm not familiar with the file replication
service, or the content of the wins or dns folders and how they are
used, but it seemed to me that if you are running (configuring) servers,
you should already know how to interpret the article.

> I'm wondering if the article is aimed mainly at system administrators
> and perhaps AV vendors. I can't see the average user being able to
> deal with all this.

That is where the expert's security concerns are valid. The average user
may screw things up pretty good by misunderstanding the intent of the
article. Server security concerns are a little different than homeuser
security concerns.

Maybe MS is a little slow in getting their mind around AV becoming
integrated with AM?


From: FromTheRafters on 18 Jan 2010 13:41

"Ant" <not(a)home.today> wrote in message
news:0I2dnThO4cLDBMnWnZ2dnUVZ8tsAAAAA(a)brightview.co.uk...
> "FromTheRafters" wrote:
>
>> A thought just occurred to me (hold the applause) - what would happen
>> if
>> I replaced the "hosts" file with an OLE2 malware file? Would the
>> browser
>> find corrupt lookup data or would the damned thing execute? :o)
>
> The hosts file is not directly accessed by browsers but by the handful
> of DLLs that implement domain name resolution and sockets.
>
> I can say that dnsrslvr.dll (DNS Caching Resolver Service) and
> rnr20.dll (Windows Socket2 NameSpace) treat it as a plain-text file,
> using the standard C runtime routines fopen and fgets to read the
> contents. No danger of OLE interfering.

Thank's Ant, I also suspect that the same may be true for the files
excluded in their list. They will be treated as data, unless there is
something *else* already compromising the machine (context and content
scanning by AM should address this - h-key...run - , not content
scanning by AV)


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Fixing a problem for a friend
Next: Automatic Renewal ZoneAlarm