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]
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ