Onderwerp: Round One: "DLL Proxy" Attack Easily Hijacks SSL from Internet Explorer

Topic
LoadLibrary / LoadLibraryEx Weakness

Release Date:
February 9, 2004

Date Reported:
Reported to Microsoft on December 9, 2003

Severity:
Medium (Interception of SSL traffic, RSA encryption, and others)

Systems Affected:
Windows 95, 98, ME;
Windows NT, 2000, XP, 2K3 (ACL limitations apply)

Summary:
A LoadLibrary / LoadLibraryEx weakness makes SSL on Internet Explorer very
vulnerable to a “DLL proxy” attack. If exploited, unencrypted data can be
intercepted before Internet Explorer (IE) uses the SSL module to encrypt the
data. Therefore, confidential information such as bank accounts and
passwords could be stolen. Many applications are vulnerable to “DLL proxy”
attack with different ramifications.

Description:
There is a system-wide Win32 weakness on Windows platforms. It is a
LoadLibrary / LoadLibraryEx weakness attributed to how it dynamically
searches and loads DLLs into processes.

(Reference: the documentation for LoadLibrary / LoadLibraryEx from Microsoft
http://msdn.microsoft.com/library/de...us/dllproc/bas
e/loadlibrary.asp - When no path is specified for calling LoadLibrary /
LoadLibraryEx the system searches the directory from which the application
is loaded first, before it searches the system or other directories.)

Microsoft has provided mitigation such as Access Control List (ACL) for
program folders using NTFS. But this mechanism can only protect a limited
segment of WINDOWS users against this “DLL proxy” attack. For example, XP
Home Edition (SP1) is installed by default with administrator privileges for
accounts and therefore ACL for program folders are wide open to be modified.
Many Windows platforms use an un-secured file system such as FAT or FAT32
without ACL protection.

To exploit this weakness, a malicious DLL module can be introduced to the
directory for a targeted application such as IE. When the application
intends to load a DLL from the system directory, it instead loads a
malicious DLL module from the application directory. The malicious DLL
module intercepts all the function calls originally intended for a DLL, such
as wintrust.dll, located in the system folder. This kind of operation has
been termed “DLL proxy” by some in the past.

OS Security has verified this weakness in IE, on Windows NT, 2000, XP:

I. Malicious DLL can be delivered using the following typical ‘delivery
techniques’:
1. Any un-patched remotely exploitable BOF vulnerability;
2. Any new program users download and run from the Internet; and
3. Any un-patched web-browser vulnerability allowing targeted file saving
within scripts.

II. Using this malicious DLL to exploit this Win32 system-wide vulnerability
as described above to:
1. Log and send out so-called “secured” SSL traffic in its unencrypted HTML
format to others on the Internet;
2. Intercept plain messages before RSA encoding and after RSA decoding and
send out the plaint text out;
3. Plant delayed DoS scheme;
4. Launch viruses/worms within normal processes as threads, and etc.

For additional details please contact: info@ossecurity.ca or visit
www.ossecurity.ca

Recommended Protection:
· Migrate from Windows 9X to a securable Windows platform such as Windows
NT, 2K, XP and follow proper security configurations to enable Access
Control List protection to mitigate “DLL Proxy” attack. For daily normal
usage, do not use an account with administrative privileges.
· Use other Web browsers than Internet Explorer to do online transactions on
Windows 95, 98 or ME;
· Download a free Secure Transaction Module (STM) program from OS Security,
Inc. to verify whether Internet Explorer is under “DLL Proxy” attack every
time when IE is used to do online transaction. Click
http://www.ossecurity.ca/code/getdl....5002&Code=4567 to download; or
· Consider using other operating systems such as Linux as an alternative to
do online secure transactions or perform sensitive data processing.

Vendor Status:
Microsoft was informed of this weakness in December 2003. As of February 5,
2004, Microsoft has not provided any indication that they intend to provide
any remedies for the affected Windows configurations.

Copyright (c) 2003-2004 OS Security, Inc.
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
OS Security, Inc.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.

Feedback
Please send suggestions, updates, and comments to:

OS Security, Inc.
http://www.ossecurity.ca
info@ossecurity.ca

--WfZ7S8PLGjBY9Voh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 09, 2004 at 01:24:04PM -0500, Disclosure From OSSI wrote:
> But this mechanism can only protect a limited segment of WINDOWS users
> against this =93DLL proxy=94 attack. For example, XP Home Edition
> (SP1) is installed by default with administrator privileges for
> accounts and therefore ACL for program folders are wide open to be
> modified. Many Windows platforms use an un-secured file system such
> as FAT or FAT32 without ACL protection.

By definition, anyone running any such system has explicitely decided to
trust all the users of the machine to act in accordance with common
shared goals.

You're confusing security mechanism with security policy; if someone's
security policy allows everyone to have administrator status, then this
is NOT a security problem, as you claim. This is legitimate use of
legitimate privileges.

--=20
Immunix Secured Linux Distribution: http://immunix.org/

--WfZ7S8PLGjBY9Voh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAJ918+9nuM9mwoJkRAgveAJ0UZ5x60LE/EsWP7/pi9o7EbdGTxACfUS9G
Dd4ulUahS5J52SS+3YQKNzg=
=PoX6
-----END PGP SIGNATURE-----

--WfZ7S8PLGjBY9Voh--

This is a total non-issue. Almost every attack vector that could place a
malicious DLL in the same directory as IE could replace IE itself or snap
screen captures. SSL is not intended to protect against attacks on either
endpoint.

This is like complaining that your safe doesn't keep people from breaking
your windows. Of course Microsoft has no intended fix, nothing is broken.

Ironically, the only real fix against someone replacing your browser with a
browser that steals data that is sent encrypted is to integrate the
retrieval/rendering logic into the operating system such that it cannot be
replaced. Something for which nearly every expert in the field has argued
that there is no rational technical justification.

In other words, if you can choose Netscape as your default browser, then an
attacker can choose a browser that tees off your decrypted data. The only
solution is for you to be unable to change your browser.

DS

> Topic
> LoadLibrary / LoadLibraryEx Weakness

While the 'attack' described in this vuln is quite feasible, it's
not confined to windows, nor does it require the use of =
LoadLibrary(Ex)?.

There are in fact two issues here:

1) runtime dynamic linking mechanisms generally make use of a search =
path.
If you have full control of a machine, or the system uses sufficiently =
lax
filesystem priviledged, it's quite easy to place your own dynamic =
library (a
DLL on windows or a .so on *nix) earlier in the search path than a =
system
library. Windows does unfortunately include a process' working directory =
as
the first directory in this search path, which is a weakness somewhat
particular to that platform.

2) Process boundaries are not security boundaries. All the processes a =
user
is running have essentially unrestricted access to each other on both
Windows and *nix variants. Even without dynamic linking tricks, there =
are
functions on both Windows and *nix platforms that can be used to modify =
any
process a user is running, to achieve essentially any end an attacker
desires. On windows, code injection techniques that do not require DLLs =
are
well known and there's plenty of example code in the aether.

It's very debatable whether or not this is a bad thing. I feel that
there should be some way to enforce security across process boundaries, =
and
doing so could make a lot of security schemes that are trivial to bypass
actually be somewhat effective ( DRM being one example ). In a thread on
Bugtraq a year ago, a lot of people disagreed for some pretty good =
reasons.

Regardless of where you stand on the issue, this vuln is nothing
new, it's just a weakness in how most OSs are designed right now.=20

>I. Malicious DLL can be delivered using the following typical =
=91delivery
>techniques=92:
>1. Any un-patched remotely exploitable BOF vulnerability;
>2. Any new program users download and run from the Internet; and
>3. Any un-patched web-browser vulnerability allowing targeted file
saving
>within scripts.

If any of these are true, you can achieve exactly what OSSec is
describing, without having to bother with the complexity of a proxy =
DLL...

OS Security has taken the red pill, but has yet to realize how deep
the rabbit hole goes.

Cheers,
~x

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.577 / Virus Database: 366 - Release Date: 03/02/2004
=20

Hi:
There is a win2k registry setting which allows the default .dll search order
to be changed.
Key:
HKLM\SYSTEM\CurrentControlSet\Control\SessionManag er
Value Name:
SafeDllSearchMode
Data:
0x1

Cheers

--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=windows-1251
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 09, 2004 at 01:31:25PM -0600, Ward Taylor wrote:
> Hi:
> There is a win2k registry setting which allows the default .dll search or=
der
> to be changed.
> Key:
> HKLM\SYSTEM\CurrentControlSet\Control\SessionManag er
> Value Name:
> SafeDllSearchMode
> Data:
> 0x1

Yeah, but won't this break a lot of programs that install their DLL's in
their own directories by design, so that they may be installed by users
without administrative privileges on older versions of Windows? I know
that Windows XP "shadows" %WINDIR% under "Documents and
Settings\username", but this is a recent development, and there are
still an awful lot of programs which rely on the 'program directory
first' search order.

G'luck,
Peter

--=20
Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence every third, but it still comprehensible.

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAKLL37Ri2jRYZRVMRAhM6AJ9XXHDw3jVFXXPzuflpOU hnBxrFOwCgsqV/
VEXqq5Cqdvg8PA+jA+2PjoI=
=C8mj
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--

In some mail from David Schwartz, sie said:
>
>
> This is a total non-issue. Almost every attack vector that could place a
> malicious DLL in the same directory as IE could replace IE itself or snap
> screen captures. SSL is not intended to protect against attacks on either
> endpoint.
>
> This is like complaining that your safe doesn't keep people from
> breaking
> your windows. Of course Microsoft has no intended fix, nothing is broken.
[...]

Oh rubbish.

Signed applications and signed DLLs and signed drivers.
Well all of those aren't there yet (only drivers for Windows),
but it's coming to a Unix near you SOONER rather than later.

Or is that the kind of thing you disable upon installation
because it gets in the way of you being able to install whatever
"you" want ?

Darren

> Signed applications and signed DLLs and signed drivers [...] coming
> to a Unix near you SOONER rather than later.

> Or is that the kind of thing you disable upon installation because it
> gets in the way of you being able to install whatever "you" want ?

Depends. Does it include the tools necessary to sign my own code?

If not, yes, I will disable it, to the point of running a different OS
if necessary.

If so, what's to stop a malware creator from using those same tools to
sign the attack vector?

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

----- Original Message -----
From: "Ward Taylor" <rfdhomer@windyplains.com>
To: <bugtraq@securityfocus.com>
Sent: Monday, February 09, 2004 7:31 PM
Subject: RE: Round One: "DLL Proxy" Attack Easily Hijacks SSL from Internet
Explorer


> Hi:
> There is a win2k registry setting which allows the default .dll search
order
> to be changed.

Out of curiosity, does that override the 0 byte .exe.local file trick to
force the application to search the local directory for the .dll first ?
http://www.jsiinc.com/subf/tip2600/rh2606.htm

Cheers.

>> Depends. Does it include the tools necessary to sign my own code?
>> If not, yes, I will disable it, to the point of running a different
>> OS if necessary.
> So you will disable a function that provides you with a trusted,
> secure, computing base because you cannot sign things yourself ?

Yes.

I'm primarily a software author, Darren. Take away my abilitiy to
write and run my own programs and having a computer becomes almost
totally pointless to me.

> Are you really trying to run a secure environment or one that you
> think you can control yourself ?

I am most certainly not going to try for security at the expense of the
whole reason I play with computers in the first place.

> Do you see what I consider to be the obvious flaw in your statement
> here and that is you would prefer to use a less secure system because
> you seem to think that you are trustworthy.

Yes. I trust myself not to write malicious code.

> How does anyone know that you're not a virus/worm writer ?

Anyone? Well, _I_ do.

Anyone else? The same way they know that of anyone: look at my record.
The code I've written, the things I've said. If you're really
paranoid, you look at the code I've written in detail (you've got the
source, after all; I don't distribute software any other way) - that
won't, strictly, assure you I'm not a malware author, but it will,
given enough diligence to convince yourself you've not missed anything,
assure you that the code you're contemplating isn't malware.

> Sooner or later, arguments that "I must do be in complete control and
> be able to do everything myself" are going to be considered
> laughable.

Perhaps. I will be perfectly willing to be laughed at by anyone
espousing such a point of view. The whole point of having computers,
to me, is to tinker with their software. If what I write can help
anyone else, so much the better.

_Someone_ has to be trusted to write non-malware. Why should it be any
less me than anyone else?

> Let me give you a hypothetical situation...

> Some time from now, all major commercial OS's come with signed
> binaries, libraries, etc and there's a major virus outbreak.

> How does the virus manage to get executed everywhere? Well, it's not
> a trusted application, for starters. (If it were then the signature
> would provide the start of an audit trail for someone to blame.)

Yeah, right. Pull the other one - it's got bells on it.

If you think such signatures would be any more worth trusting than SSL
certs are today, I think you're deluding yourself. Anyone who bothers
to cobble up something letterhead-like and fax it can get an SSL cert
in practically any name desired - or so I'm given to understand; I've
never tried it myself. I don't for a moment believe these signatures
will be significantly better.

Not to mention that you started out talking about "major commercial
OSes", which by their record are significantly _less_ trustworthy than
the major open-source OSes. I think open-source OSes are past
GandhiCon 2 and in some respects up to 3; I expect them to keep going.

> One reaction might be that government says you are not allowed to
> network, either directly or indirectly, computers that allow unsigned
> applications to run on them.

Completely unenforceable. Practically all the network links, all the
way from the peering points on down, are privately owned, and the
exceptions are generally not accessible to the public for transport
between third parties; you are postulating "government" telling private
entities that they may not permit their own infrastructure to be used
by whomever they may choose. I predict most of those entities will not
take kindly to such dicta.

> Now what are you going to do ?

Positing what you describe, implausible as I find it - I don't know. I
might take a civil-disobedience stance, though if it got to the point
where such a thing were enacted, the society would perforce have
changed to enough of a dictatorship that such a stance would probably
not be tolerated at all. Most likely, I just leave, or do not enter,
the country in question. There are lots of other countries, and they
will not all be that tyrannical.

Potentially, layer a new network atop the then-existing one. If there
remains any programmability at all, it will be extremely hard to
prevent that - and if there doesn't, a whole lot of common and useful
things will be rendered impossible.

At the very worst, stop using computers, or at least stop using
networked computers.

> And that of course begs the question, why should the rest of the
> world be expected to trust you ?

My record, of course, same as anyone else "the rest of the world" is
"expected to trust".

> It's been rumoured that the successor to XP will be incompatible in a
> significant way such that old applications will not run. What if
> this kind of platform was part of it and the Microsoft idea of
> solving the virus problem is to disallow execution of untrusted
> applications, by default, without so much as a prompt to ask a user
> yes or no, rendering all prior applications incompatible ?

We can wish. Most of the Windows folk probably wouldn't mind; software
hackers like me are, by and large, perfectly content doing their stuff
under non-Microsoft OSes - indeed, many of them strongly prefer it.

Of course, putting it into the hardware would defeat that, though I
daresay it could be gotten around - and if not, I simply would have no
use for such a machine. Unless you want to get back to positing severe
dictatorial controls over what computers people use, there isn't much
that can be done to stop this; the computers I have will still do what
they always did, until they break - which, when they're taken good care
of, seems to be pretty seldom.

> - by building up a proper TCB we eliminate execution of worms whilst
> letting people continue to do what they want.

Only for values of "people" not including programmers, even programmers
to the extent of scripting applications. The line between programming
and non-programming is tough to draw; as an extreme example, it
wouldn't surprise me if a decent hacker could build a Turing machine in
a spreadsheet, given a reason to bother.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

In some mail from der Mouse, sie said:
>
> > How does anyone know that you're not a virus/worm writer ?
>
> Anyone? Well, _I_ do.
>
> Anyone else? The same way they know that of anyone: look at my record.

That's not good enough. Sooner or later, the software industry is
going to have to change and declare that "no warranty" software
should be confined to isolated systems.

Saying "look at my record" is bogus. I'm sure history is full of
people who appeared to be doing "good things" but later turned into
rotten eggs. The public, at large, needs isolation from that.

> > Sooner or later, arguments that "I must do be in complete control and
> > be able to do everything myself" are going to be considered
> > laughable.
>
> Perhaps. I will be perfectly willing to be laughed at by anyone
> espousing such a point of view. The whole point of having computers,
> to me, is to tinker with their software. If what I write can help
> anyone else, so much the better.

Then I suppose, using the other points I was making, do it in a
fashion that certifiably poses no risk to anyone else - i.e. tinker
with them in a quarantined/isolated environment.

> _Someone_ has to be trusted to write non-malware. Why should it be any
> less me than anyone else?

Because you (or should I say individuals) are not what I would
consider well placed to provide the sort of backing in terms of
guarantees & warranty & liability protection that will sooner or
later come into being. Much as industry elsewhere is regulated
in what standard of products is suitable for public consumption,
sooner or later the bell will toll for software and at that point
I expect the bar to be raised beyond the reach of the likes of you
or I or other free software projects. Unless we want to continue
to put up with buggy software and have no avenue for recourse.

> > Let me give you a hypothetical situation...
>
> > Some time from now, all major commercial OS's come with signed
> > binaries, libraries, etc and there's a major virus outbreak.
>
> > How does the virus manage to get executed everywhere? Well, it's not
> > a trusted application, for starters. (If it were then the signature
> > would provide the start of an audit trail for someone to blame.)
>
> Yeah, right. Pull the other one - it's got bells on it.
>
> If you think such signatures would be any more worth trusting than SSL
> certs are today, I think you're deluding yourself. Anyone who bothers
> to cobble up something letterhead-like and fax it can get an SSL cert
> in practically any name desired - or so I'm given to understand; I've
> never tried it myself. I don't for a moment believe these signatures
> will be significantly better.

If there is a process that is at fault then it gets fixed and there
is a trail of who is to blame for the inadequate checking. Just as
there is a trail back to the supplier of a certificate if there is a
problem with one issued. Whether or not software certificates become
that easy/meaningless is a problem for the software companies.

> > One reaction might be that government says you are not allowed to
> > network, either directly or indirectly, computers that allow unsigned
> > applications to run on them.
>
> Completely unenforceable. Practically all the network links, all the
> way from the peering points on down, are privately owned, and the
> exceptions are generally not accessible to the public for transport
> between third parties; you are postulating "government" telling private
> entities that they may not permit their own infrastructure to be used
> by whomever they may choose. I predict most of those entities will not
> take kindly to such dicta.

Tell me, can you connect any random piece of hardware to your phone
line, legally ?

Why should you just be able to connect any random piece of hardware
to the Internet ? How does anyone know that what you are connecting
won't somehow endanger its stability ?

Tell me, if that is put on the platter as being the cost of defeating
worms that otherwise flood the Internet, can't you see most people
being willing to sacrifice it ?

> > And that of course begs the question, why should the rest of the
> > world be expected to trust you ?
>
> My record, of course, same as anyone else "the rest of the world" is
> "expected to trust".

That's meaingless and valueless if your software comes with a
disclaimer that provides no warranty or guarantee.


I'm not going to discuss points that are more "nuts and bolts", such as
how do programmers develop in such environments, etc as I believe it is
just machinery that will fall into place as required.

Darren

> That's not good enough. Sooner or later, the software industry is
> going to have to change and declare that "no warranty" software
> should be confined to isolated systems.

It is not the software industry's place to decide that; that is for
software consumers to decide...or not.

> Tell me, can you connect any random piece of hardware to your phone
> line, legally ?

I think so. Unless you consider telco tariffs "law", and possibly even
then. (Of course, this will vary with jurisdiction.) At most, I may
be liable for damages caused - but it's hard to hurt even the CO end of
a POTS line; this is a system designed in the expectation of lightning
strikes. Disrupting the phone system as a whole is even harder.

> Why should you just be able to connect any random piece of hardware
> to the Internet ?

The Internet is an agglomeration of private networks. The phone system
isn't, or at least isn't in the same sense.

This is the whole common-carrier argument over again. If you think the
net is going to turn into a common carrier, fine, that may be a
defensible point of view, but you shouldn't argue from analogy that
assumes it without making that assumption explicit.

> Tell me, if that is put on the platter as being the cost of defeating
> worms that otherwise flood the Internet, can't you see most people
> being willing to sacrifice it ?

Yes, initially; I expect them to discover otherwise after they find out
the consequences (and discovering also how hard it is to roll back such
a change).

I also fully expect that if "the Internet" is bludgeoned into
common-carrier status, private - ie, unregulated - lines will promptly
spring up in parallel with it (you _definitely_ can connect any old
thing to a phone line, when it's a privately owned phone system (whose
owner okays), rather than a common-carrier telco line)...and the
common-carrier Internet will wither as the new, private-line,
neo-Internet evolves back into more or less what we have.

>>> And that of course begs the question, why should the rest of the
>>> world be expected to trust you ?
>> My record, of course, same as anyone else "the rest of the world" is
>> "expected to trust".
> That's meaingless and valueless if your software comes with a
> disclaimer that provides no warranty or guarantee.

I don't expect software to routinely come with warranty/guarantee in my
lifetime or yours. If some government tries to mandate it, I believe
that all that will happen is that software industry in the affected
jurisdiction will wither and die. The state of the art is not yet to
the point where such a thing is feasible, and I'm not convinced it
_ever_ will be, much less anytime soon.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

In some mail from der Mouse, sie said:
>
> > Signed applications and signed DLLs and signed drivers [...] coming
> > to a Unix near you SOONER rather than later.
>
> > Or is that the kind of thing you disable upon installation because it
> > gets in the way of you being able to install whatever "you" want ?
>
> Depends. Does it include the tools necessary to sign my own code?

Not with the same key that signs software provided by the OS supplier,
that's for sure. Maybe not even at all.

> If not, yes, I will disable it, to the point of running a different OS
> if necessary.

So you will disable a function that provides you with a trusted, secure,
computing base because you cannot sign things yourself ? Are you really
trying to run a secure environment or one that you think you can control
yourself ? Do you see what I consider to be the obvious flaw in your
statement here and that is you would prefer to use a less secure system
because you seem to think that you are trustworthy. How does anyone
know that you're not a virus/worm writer ? Do we just have to take
your word for it ? The idea behind TCB moves that consider the user
"hostile" is not without merit.

Sooner or later, arguments that "I must do be in complete control and
be able to do everything myself" are going to be considered laughable.


Let me give you a hypothetical situation...

Some time from now, all major commercial OS's come with signed binaries,
libraries, etc and there's a major virus outbreak.

How does the virus manage to get executed everywhere? Well, it's not a
trusted application, for starters. (If it were then the signature would
provide the start of an audit trail for someone to blame.)

One reaction might be that government says you are not allowed to network,
either directly or indirectly, computers that allow unsigned applications
to run on them.


Now what are you going to do ? Disconnect your computer or argue that
you cannot trust the manufacturers and can only trust the programs you
compile yourself ? And that of course begs the question, why should
the rest of the world be expected to trust you ? Are you going to be
in a position where you can afford the kind of liability insurance
required to be a trusted source of computer applications ? Yes, this
sort of requirement may well and truely be the death of shareware
programs.

It's been rumoured that the successor to XP will be incompatible
in a significant way such that old applications will not run.
What if this kind of platform was part of it and the Microsoft idea
of solving the virus problem is to disallow execution of untrusted
applications, by default, without so much as a prompt to ask a user
yes or no, rendering all prior applications incompatible ? Well,
maybe that is hoping for too much.


I suppose to summarise, I see it something like this:

- people want applications to be able to provide extra value by
running scripts, binaries, easily, etc;

- worms exploit desired featurisms by exploiting people and should
be considered to be hostile/untrusted applications;

- by building up a proper TCB we eliminate execution of worms whilst
letting people continue to do what they want.

Darren

Thanks a lot for everyone's comments and feedback on this disclosure. We
spent time on this old issue as it has an extremely high malicious targeted
attack capability and very easy to exploit.

After Jeremy's IE targeting file saving vulnerability was disclosed in
November 2003, we came across the idea to test whether it was possible to
hijack SSL on IE. Boom, it took us only one day to research and successfully
test the exploit code! That's the reason why we did not disclose it in
details. It is extremely easy to exploit. Just look into the SDK
documentation and everything is right there for you to exploit. What you
need to hijack SSL from IE is one function call from one DLL file. When we
tested it out, Windows OS (ACL was not considered then), IE and leading AV
software did not provide any kind of alert or alarm. The easiness to exploit
this weakness, and the failures at multiple layers to detect this intrusion
led us to categorize this as a serious problem.

This exploit is far more sinister and hidden than the quite obvious ones
used by phishing. Compared to keylogger spyware, this exploit is much more
targeted and efficient. Keylogger spyware returns high volumes of
information which need a lot of filtering to obtain useful information.
Alternatively, someone can gain a lot of confidential info from
"data-mining" raw data before SSL encryption. This exploit will turn the
so-called "secure" transactions into completely insecure ones.

When we disclosed this to Microsoft, we were told that this feature has
existed for more than ten years. We could not understand why Microsoft
cannot take some protective measures against this simple and easy exploit of
"DLL proxy" attacks if they have known of the potential risk of "DLL proxy"
or "DLL injection" for years. In light of wide-spreading MyDoom, the latest
disclosure from eEye and Microsoft’s subsequent patch announcement (04-007),
together with other vulnerabilities in other applications on Windows, don't
you think that the first line of defense against intrusion onto a PC for
normal users is almost not there?

When we dealt with Microsoft, Microsoft tried to push across the concept
that a malicious attack erasing a user’s hard drive is far worse that
obtaining access to information intended to be encrypted using SSL!? Only
protecting against the entrance of an attack is not enough to mitigate
against threats. By the way, they did not state "the program can DDoS ..".

When IE switches into https mode, it brings up the "security alert" dialog
(unless disabled)that states: "You are about to view pages over a secure
connection. Any information you exchange with this site cannot be viewed by
anyone else on the web.". Is that whistling in the dark? Don't you agree
that the alert should be modified a little bit?

We have to sing the same song posted by Marc Maiffret from eEye:
U can't trust this
U can't trust this ...
MyDoom'd zombies DDoS U
Ur SSL is so easy to break...
What else is left to be trustworthy?

Regards

Peter Huang
http://www.ossecurity.ca/

der Mouse wrote:

> > Signed applications and signed DLLs and signed drivers [...] coming
> > to a Unix near you SOONER rather than later.
>
> > Or is that the kind of thing you disable upon installation because it
> > gets in the way of you being able to install whatever "you" want ?
>
> Depends. Does it include the tools necessary to sign my own code?
>
> If not, yes, I will disable it, to the point of running a different OS
> if necessary.
>
> If so, what's to stop a malware creator from using those same tools to
> sign the attack vector?

You don't have to store the signing key on every host which needs to
run the signed binaries.

--
Glynn Clements <glynn.clements@virgin.net>