OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Features versus Security versus User Education
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Features versus Security versus User Education

  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: Re: Features versus Security versus User Education
  • From: Alex McKelvey <alexpshift.org>
  • Date: Mon, 29 Mar 1999 23:07:46 -0500
  • Approved-By: Russ.CooperRC.ON.CA
  • Reply-To: alexpshift.org
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
        Centralized management of VBA for current and existing MS products may not be
as far fetched as it sounds. I've poked around what I think is the actual
implementation of VBA, some DLLs in the common files directory. After taking a
closer look with dumpbin I found they export common VBScript functions like
DateDiff, FileLength and the like. If these DLLs are what MS products use to
process the scripts then it's possible to write a small "shim" library which
would be able disallow operations based on some kind of security profile setup
by an admin. Things like file access from VBA could be controlled globally or
on a wks to wks basis. CreateObject could be limited to only certain classes or
disabled entirely, and maybe only certain files or registry keys could be
accessed from within a macro. I'm no developer and I don't have much idea of
how much work this would entail. I do know that this sort of thing was used
recently in that KnownDLLs hack. Applications and system services wanting to
use shell32.dll actually called a different library (because of some caching
security hole) with would be able to do anything it liked in the security
context of the caller and then pass off the processing to the real shell32.dll.
        In some environments I've worked in, macros are a valuable and time saving
tool that I wouldn't want to give up. But there are so many "features" that
could be exploited, with potentially damaging consequences. A lot of people I
know wouldn't think twice about a macro in an email sent from someone they
know, a stranger definately but not someone they routinely exchange documents
with. I think functionality should not be compromised because there are many
that rely on it, and user education won't stop all attacks. The approach Data
Fellows has taken is that of allowing an entire macro which has been
explicitely allowed or denying an entire macro which has not been explicitely
allowed. In some environments it may not be desireable to have to call up the
admin whenever you need to run a new or modified macro. If the admin could
manage macros not by signatures and trust, but on the actual content of the
macro it would make things a whole lot easier and more secure.

Alex McKelvey
----
http://www.ajcs.on.ca/
http://www.pshift.org/
rootajcs.on.ca
alexpshift.org