full-disclosure - ADODB.Stream object

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3F4CAFA1.26304.9814E4B5@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: ADODB.Stream object

"Richard M. Smith" <rms@...puterbytesman.com> wrote:

> Agreed.  However, I would go one step further.  I don't think that the
> typical user has a need for HTML Applications and Windows Scripting
> Host.  Both of these features along with their associated ActiveX
> controls should be disabled by default in Windows XP.  They make writing
> malware too easy.  

Sadly, that horse has already bolted.  In fact, there's a stampede that 
will prevent that stable door being closed at all...

Recall that although available as a separate component (for use with 
W95, NT 4.0 pre-<some service pack> and possibly NT 3.51) WSH is 
effectively part of IE 4.0 (or 4.01?) and later, and thus (thanks to 
the the DoJ defense) "a core part of the OS".

Perhaps because of this (or just through outright laziness and/or 
stupidity) some product installation routines write customized .HTAs 
for use (later) in the installation process and some (sometimes the 
same ones) also  write custom VBS scripts for the same reason.  These 
processes expect that full WSH functionality will be available (and 
seldom, if ever actually _check_ that WSH is even installed).  Because 
the "system requirements" for the software being installed usually 
includes "IE <version 4.01 or later>" or an OS shipped with such a 
version of IE, the installer assumes that _all_ IE components are 
installed, enabled and configured to work as per the defaults.

In fact, wasn't it this list yesterday or the day before where someone 
posted a link to a KB article explaining that the installer for the 
.NET Framework could run to completion yet fail to install certain 
components because of "script blocking" and such features in various 
virus scanners and other security products?  (If not F-D it may have 
been Bugtraq or NTBugtraq -- I can't be bothered searching for it...)

Regards,

Nick FitzGerald