SUPER SPOOF DELUXE Re: [Full-Disclosure] Microsoft and Security

[http-equiv@excite.com]

>Here's a quick and dirty demo injecting malware.com into
>windowsupdate.microsoft.com :)

>http://www.malware.com/targutted.html

Thomas Kessler was kind enough to inform that this is not new,
but in fact on old "issue" with Internet Explorer which by all
accounts was supposed to be "patched" back in 1998[?]:

Microsoft Security Program: Microsoft Security Bulletin (MS98-
020) Patch Available for 'Frame Spoof' Vulnerability

http://www.microsoft.com/technet/security/bulletin/ms98-020.mspx

Quite clearly this contraption known as Internet Explorer is
just broken. It's oozing pus from every pore at this stage.

If indeed the issues are the exact same.

You'd better wipe hands of it anyway.

We give up.

--
http://www.malware.com

[http-equiv@excite.com]

What an utterly pathetic scenario you present. Obviously you're
blissfully unaware of the current security trend of site
spoofing, 'phishing', url spoofing, DNS spoofing, zone spoofing
and on and on and on.

and of course now very the latest 'security expert spoofing' !

<!--

"Your subject makes it sound like this is a spoofing
vulnerability"

You have to look at the prerequisite attack scenario. You are
surfing to
some random site and out of nowhere it opens WellsFargo.com or
WindowsUpdate. At this point you are thinking one of 2 things,
either

"What the.. I didn't go to WindowsUpdate/WellsFargo .. Let me
just close
that window .. Damn popups"

or

"Hey how nice, WindowsUpdate/WellsFargo magically appeared in
front of
me and I didn't even intend to go there .. I was just surfing
for porn
... Let me hurridly download some stuff from there and give it my
account
details"

-->



--
http://www.malware.com

[Alun Jones]

Justin Wheeler <mailto:jwheeler@datademons.com> wrote on Monday, June
28, 2004 5:42 AM:
> Perhaps that'd be a better argument, if there weren't
> countless patches
> from MS in the past that broke other things..

.... okay, so you're arguing that even more QA and more testing should be
done... but in far less time.

> And I'd also be more likely to believe that if there weren't
> MS patches out
> there that fix one particular bug, but completely ignore
> other ones that are
> nearly IDENTICAL to it.

.... and while you're at it, you'd like us to spend even more time searching
for ways to expand our search for the bug's potential impact, rather than
releasing a smaller fix, with minimal impact, as soon as possible.

I can't even remotely call myself a Microsoft spokesman - but I am trying to
figure out exactly what you're looking for. Perhaps it's just a platform to
vent at Microsoft - fine, vent away. If you have any suggestions for
improving the process, perhaps you should try and express those suggestions
in a coherent manner that could be used, rather than choosing several
contradictory stances and insisting that Microsoft satisfy them all.

Alun.
~~~~

[Justin Wheeler]

The simple argument I was making was that if MS' "testing process" is what
keeps patches from coming out in a timely manner, perhaps they should
actually be of decent quality. When you're getting patches that are both
slow to release, as well as adversely affecting the systems they're being
installed on, MS has met neither of their agends.

Justin

----- Original Message -----
From: "Alun Jones" <alun@texis.com>
To: "'Justin Wheeler'" <jwheeler@datademons.com>; "'Radoslav Dejanovic'"
<radoslav.dejanovic@opsus.hr>; <bugtraq@securityfocus.com>
Sent: Sunday, July 04, 2004 5:06 PM
Subject: RE: Microsoft and Security


> Justin Wheeler <mailto:jwheeler@datademons.com> wrote on Monday, June
> 28, 2004 5:42 AM:
> > Perhaps that'd be a better argument, if there weren't
> > countless patches
> > from MS in the past that broke other things..
>
> ... okay, so you're arguing that even more QA and more testing should be
> done... but in far less time.
>
> > And I'd also be more likely to believe that if there weren't
> > MS patches out
> > there that fix one particular bug, but completely ignore
> > other ones that are
> > nearly IDENTICAL to it.
>
> ... and while you're at it, you'd like us to spend even more time
searching
> for ways to expand our search for the bug's potential impact, rather than
> releasing a smaller fix, with minimal impact, as soon as possible.
>
> I can't even remotely call myself a Microsoft spokesman - but I am trying
to
> figure out exactly what you're looking for. Perhaps it's just a platform
to
> vent at Microsoft - fine, vent away. If you have any suggestions for
> improving the process, perhaps you should try and express those
suggestions
> in a coherent manner that could be used, rather than choosing several
> contradictory stances and insisting that Microsoft satisfy them all.
>
> Alun.
> ~~~~
>
>

[Radoslav Dejanovic]

> figure out exactly what you're looking for. Perhaps it's just a platform
> to
> vent at Microsoft - fine, vent away. If you have any suggestions for
> improving the process, perhaps you should try and express those
> suggestions
> in a coherent manner that could be used, rather than choosing several
> contradictory stances and insisting that Microsoft satisfy them all.

IMHO, security issues in Microsoft OS are closely interwined, due to the
centralized nature of the software. While you can easily fix Mozilla or
KHTML problem without worying that it is going to break some part of Linux
kernel, this might be of great concern on Windows platform. I think
Microsoft got caught with all this security stuff; remember that up to
Windows NT there weren't any serious security measures on desktop and
networking side. Just as Microsoft got caught with the Internet (if you
remember "MSN is going to be the network of the future" statements back
then, and all those plans to put communication sattelites in the orbit),
they got caught with security issues - if I may say, Redmond
underestimated them. Now, it is going to be tough one to solve: software
is centralized and interdependent, it will teke time to solve all those
issues while breaking as few things as possible, and the transition simply
*must* be easy for the end user, not to mention the business world that
needs to get things fixed, not broken up. So I belive this security game
is going to be tough and expensive for Microsoft, mainly for the reason
that they integrated a lot of things. This bunch of interdependencies is
going to give them a big headache.
If you ask me for one advice to help resolving this in the future, it
would be: stop integrating, diversify! After all, this Unix philosophy of
having a myriad of small tools to solve comnplicated tasks has proven to
be tougher for end user, but safer and more versatile in the end.
But for Microsoft it has been just the opposite strategy. With it's set of
great advantages, but with a set of painful disadvantages as well.

--
Radoslav Dejanovic
founder and director
Operacijski sustavi d.o.o.
http://www.opsus.hr

[Alun Jones]

Justin Wheeler <mailto:jwheeler@datademons.com> wrote on Monday, July
05, 2004 10:58 AM:
> The simple argument I was making was that if MS' "testing
> process" is what
> keeps patches from coming out in a timely manner, perhaps they should
> actually be of decent quality. When you're getting patches
> that are both
> slow to release, as well as adversely affecting the systems
> they're being
> installed on, MS has met neither of their agends.

It's not "either perfect quality assurance or immediate patching", sadly.

We spend so much time in our binary world, that we forget that real and
complex human processes are not binary - there are a large number of shades
of grey.

The immediate patch carries maximum risk, and the perfect patch requires
unconscionable amounts of time to verify its correctness. Between those two
endpoints, however, you'll find a huge variance in what is acceptable risk
of damage from a patch versus acceptable delay to test. And unfortunately,
neither of those two values is a) measurable, or b) the same for each user.

It's a balancing act, and one performed without a net. And we've only
touched on two of the variables in this balance. There's also third-party
software, whose vendors tend to get a little tetchy when their software
doesn't work the same way it has for years, even if it's because they're
relying on undocumented and unsecure behaviour. There's probably a dozen
other variables that you need to consider. If you've ever had to respond to
a security vulnerability (perhaps if you've had to respond to more than
one), you'll understand the way that the process works, and that a rushed
untested 'patch' is worse than the worst tested patch.

A tested patch will at least work on the majority of systems. An untested
patch runs a high risk of not working at all. The problems you've pointed
to are issues with outliers - usually customers running specialised software
- not widespread damage to people with mundane configurations. Usually such
outlier customers would be the ones most able to test their own
configurations prior to rolling out any patch, though, and I would always
suggest that those who can test, should test, any patch or upgrade in their
own environment prior to patching.

Microsoft employs people who care about producing good software. We're all
indoctrinated from day one that our software is used by everyone - our
parents, our neighbours, our children... It's perhaps a unique situation
compared to producers of the other OSs, where the users are usually limited
to particular sections of the community.

I really don't think you'll find much truck with the idea that Microsoft
employees are happy to leave their mother's home machine, or those of the
general public, open to infection.

Alun.
~~~~

[Jason Coombs]

Alun Jones wrote:
> ... okay, so you're arguing that even more QA and more testing should be
> <snip>
> releasing a smaller fix, with minimal impact, as soon as possible.
> <snip>
> improving the process, perhaps you should try and express those suggestions
> in a coherent manner that could be used
....

Aloha, Alun.

My suggestion is a simple one that all software developers can manage to
incorporate into their busy schedules and tight budgets:

Hire an expert to conduct a thorough forensic review of the software
before it is released, and publish the forensic analysis report.

Any vulnerabilities, flaws, areas that need additional work, portions
that were built by subcontractors of questionable skill or loyalties,
portions that were offshored, features that the programmers themselves
warn are not yet done by placing comments in the source code, third
party libraries or code or algorithms that may create intellectual
property liability for the end user, and all other issues of computer
forensics and computer law should be spelled out as clearly as possible
by any company that develops and distributes software to the public.

Anyone who does not publish a forensic analysis report along with their
software should publish the source code, whether or not they release
legal rights to that source code under an open source or free software
license.

The computing public should not have to reverse engineer software
products in order to figure out what they do to the computers on which
they are installed and used.

Even the Department of Justice knew better than to allow the FBI to
build and deploy law enforcement computer technology without hiring an
expert to write a forensic report on the product, and the FBI doesn't
try to sell "Carnivore" to anyone.

http://www.epic.org/privacy/carnivore/

Final Independent Technical Review of the Carnivore System
http://www.epic.org/privacy/carnivore/carniv_final.pdf

We should require software vendors to take this stuff seriously.

Sincerely,

Jason Coombs
jasonc@science.org

[David F. Skoll]

On Mon, 5 Jul 2004, Alun Jones wrote:

> The immediate patch carries maximum risk, and the perfect patch requires
> unconscionable amounts of time to verify its correctness. Between those two
> endpoints, however, you'll find a huge variance in what is acceptable risk
> of damage from a patch versus acceptable delay to test. And unfortunately,
> neither of those two values is a) measurable, or b) the same for each user.

That's true. However, Microsoft has a much higher record of patches that
break things than most other vendors. I don't believe that's because
the people who write the patches are less competent, but I do believe it's
because they are patching a horribly-designed system.

Microsoft has bundled together so much stuff and interconnected so many
applications with parts of the operating system that the system is extremely
fragile, and any change is likely to have unforseen side effects.

I can't recall ever installing a Linux vendor patch that has broken anything
on my systems (I'm sure it has happened, just not to me.) That's because
the various bits of Linux (or UNIX for that matter) are quite isolated:
The windowing system runs as a normal user process; the Web browser is
not "part of" the operating system; and filenames do not have magical
side effects (.exe != chmod a+x), to name a few problems with Windows.

I believe Microsoft is plagued with security problems and its patches
are plagued with breakage problems because Windows is just a mess.

Regards,

David.

[Adam Shostack]

On Tue, Jul 06, 2004 at 03:04:01PM -0400, David F. Skoll wrote:
| On Mon, 5 Jul 2004, Alun Jones wrote:
|
| > The immediate patch carries maximum risk, and the perfect patch requires
| > unconscionable amounts of time to verify its correctness. Between those two
| > endpoints, however, you'll find a huge variance in what is acceptable risk
| > of damage from a patch versus acceptable delay to test. And unfortunately,
| > neither of those two values is a) measurable, or b) the same for each user.
|
| That's true. However, Microsoft has a much higher record of patches that
| break things than most other vendors. I don't believe that's because
| the people who write the patches are less competent, but I do believe it's
| because they are patching a horribly-designed system.

That's a common perception, but when we looked at vendor patch
updates, as an indicator of patches that have problems, we didn't see
it. And really, we looked. We would have been happy to tweak vendors
for releasing shoddy patches, because bad patches stand out in an
admin's memory, while ok patches cognitively disappear.

Now, it could well be that the problems that cause MS to pull a patch
and replace it are more severe than the ones that cause a Linux vendor
to do so. We didn't examine that, although I'd love to see someone do
that study. What we found was that about 1 patch in 6 gets replaced
at some point, and most of that happens in about 30 days or less.

Adam

Timing the Application of Security Patches for Optimal Uptime
Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, Chris
Wright, and Adam Shostack. Presented at the USENIX 16th Systems
Administration Conference (LISA 2002), Philadelphia, PA, December 2002
http://www.homeport.org/~adam/time-to-patch-usenix-lisa02.pdf

[Valdis.Kletnieks@vt.edu]

--==_Exmh_-1257345172P
Content-Type: text/plain; charset=us-ascii

On Mon, 05 Jul 2004 16:10:36 PDT, Alun Jones <alun@texis.com> said:

> Microsoft employs people who care about producing good software. We're all
> indoctrinated from day one that our software is used by everyone - our
> parents, our neighbours, our children... It's perhaps a unique situation
> compared to producers of the other OSs, where the users are usually limited
> to particular sections of the community.

Yes, parts of Microsoft *are* trying to do better, but there's a limit to
what any single programmer can achieve without some serious buy-in from
high-level project leaders.

Unfortunately, there's obviously a disconnect at *some* level, because they
keep shipping software that's broken in very fundemental and recognized ways
(the concept of "zoned", ActiveX, and other such stuff we've known for *YEARS*
is a bad security idea). There's just too much lock-in to the concept that
since your software is used by everyone, it has to have all sorts of bells
and whistles to make life easier for everyone...

.... including black hats.

Be honest now - how many times in their career has the average Microsoft
programmer been indoctrinated with "Be Featureful!", and how many times have
they heard "Be security-minded paranoids!"? Remember to count double/triple
scores for what they heard the first 6-9 months they were there and
absorbed the culture.

Proof that Microsoft still needs to re-educate some high-level people: the
fact that there was *any* thought given to making SP2 only install on
"legal" copies and locking out pirated copies. The number of people running
pirated copies that actually will buy legit ones just to install SP2 is quite
likely tiny - but the number of people running pirated ones that would end
up remaining insecure is much larger. This one *should* have been a no-brainer:

"We screwed up, our software sucked security-wise, and to make up for it,
we're giving out a freebie update for *everybody* and swallowing the profits
from the 23 people who would otherwise go legit just to install SP2".

> I really don't think you'll find much truck with the idea that Microsoft
> employees are happy to leave their mother's home machine, or those of the
> general public, open to infection.

Much would be explained by the thesis that the person(s) causing the
disconnect mentioned above don't have mothers... ;)


--==_Exmh_-1257345172P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA7rf/cC3lWbTT17ARAjfUAKCIv+bc9G+hyUafOS6VHGNfaUhXRwCgue IN
zDoqQ3K81q6BAflgO6B2bgY=
=cbPG
-----END PGP SIGNATURE-----

--==_Exmh_-1257345172P--

[Charles Otstot]

Valdis.Kletnieks@vt.edu wrote:

>On Mon, 05 Jul 2004 16:10:36 PDT, Alun Jones <alun@texis.com> said:
>
>
><snip>
>
>Proof that Microsoft still needs to re-educate some high-level people: the
>fact that there was *any* thought given to making SP2 only install on
>"legal" copies and locking out pirated copies. The number of people running
>pirated copies that actually will buy legit ones just to install SP2 is quite
>likely tiny - but the number of people running pirated ones that would end
>up remaining insecure is much larger. This one *should* have been a no-brainer:
>
><snip>
>

I won't argue the rest of your points, however, this one I would
consider invalid. Here, I have to agree with Microsoft's original
concept. Those with pirated copies have no claim to, nor a right to, any
fixes (security or otherwise) from Microsoft. While an argument could
be made that not permitting these people to have fixes could endanger
innocent users and others with legal copies, this is at best a morally
ambiguous and thin argument. The simple fact is, those who use pirated
software (be it Microsoft's or anyone else's), are simply thieves who do
not deserve to reap any benefits from their actions.


Charlie

[Lucas Holt]

On Jul 12, 2004, at 7:47 AM, Charles Otstot wrote:
>
> I won't argue the rest of your points, however, this one I would
> consider invalid. Here, I have to agree with Microsoft's original
> concept. Those with pirated copies have no claim to, nor a right to,
> any fixes (security or otherwise) from Microsoft. While an argument
> could be made that not permitting these people to have fixes could
> endanger innocent users and others with legal copies, this is at best
> a morally ambiguous and thin argument. The simple fact is, those who
> use pirated software (be it Microsoft's or anyone else's), are simply
> thieves who do not deserve to reap any benefits from their actions.
>
>
> Charlie
>

I have to disagree with this. Its not about endangerment.. legit users
must upgrade their software to avoid risk. The problem is that
internet worms eat up bandwidth on the net and slow down servers and
clients with useless requests. If we can limit the number of users who
run antique software, the whole world is a better place. :)

Then we just have to worry about other malicious attacks and script
kiddies playing.

Lucas Holt
Luke@FoolishGames.com
__________________________________________________ ______
FoolishGames.com (Jewel Fan Site)
JustJournal.com (Free blogging)