MS web designers -- "What Security Initiative?"

[Nick FitzGerald]

The MS Security Initiative is an utter sham.

I commented on the uselessness of the "new, improved" MS Security
Bulletin web pages when they were "upgraded" to .mspx form. In doing
so I rather rudely pinned the blame for the unusability of the new
Security Bulletin pages on the MSRC staff -- as subsequent Email from
MSRC confirmed, they simply provide the content which is then served to
the world at the whim of one or other of MS' web design teams.

And, to give them their dues, they "fixed" those pages so "weird" folk
like me whose security sensibilities require surfing with scripting
disabled could actually read all the content of those pages without
having to resort to the ugliness and inconvenience of source viewing
and the like. (Of course, they had to do it in such a way that the
original, security-antagonistic "improved features" -- mainly of the
"flying pink elephant" kind -- were retained, thereby increasing the
size and complexity of all those pages...) Singling out MSRC for the
blame in that case at least had a chance of getting it fixed so a
resource I have to use was at least usefully usable again.

For reasons I now forget, I never got around to the follow-up post on
much the same issues as they were present in the "Order the Windows
Security Update CD" page -- the page is designed to be unusable unless
you have scripting enabled in your browser (from memory it used a
script to submit the initial stage of the order form -- choosing the
country your ordered CD was to be delivered to). I know scripting is
enabled by default in the joke of a program that passes for a web
browser in a default Windows installation, but why do MS web designers
assume the rest of the world is as security antagonistic (or perhaps
just as security ignorant?) as they themselves are?

Anyway, the reason for today's swing at MS' web designers -- spam.

I just had occasion to attempt to revisit a bookmarked MS-hosted page
dealing with spam, specifically:

http://www.microsoft.com/mind/1299/spam/spam.htm

Imagine my surprise when an apparently successful page load resulted in
an entirely blank window... From viewing the page source the problem
was apparent -- aside from the the minimum structural requirements of a
proper HTML page, the page consisted solely of a script tag that pulls
in its content from:

http://www.microsoft.com/mind/mind.js

In turn that is a simple script that lowercases the URI of its
container page (which is the .../spam.htm URI from above because the
script is included into that page's "head" section), searches that for
the last instance of ".htm", replacing it with ".asp" then does a
window.parent.location.replace to redirect the page. With scripting
enabled the result of trying to visit the original target URI is a near
instant redirect to:

http://www.microsoft.com/mind/1299/spam/spam.asp

Independent of the gross stupidity of assuming everyone is dumb enough
to browse with scripting enabled that this entails, it also strikes me
as terribly inefficient from the user's perspective (but maybe that's
an issue you're unlikely to be able to convince the staff of the
wealthiest company on Earth, who all sit on fast network connections
and would rather save a few grand by not adding a box or two more to
the server farm by pushing out stupid little script pages to get their
web visitors to use network bandwidth and their own CPU power to
calculate web redirects on MS' behalf).

Was it really too much work to remap all the ".htm" content under the
http://www.microsoft.com/mind/ tree to ".asp"??

Of course, the observant among you will have noticed that the above
page has not yet been converted to ".mspx" format and still languishes
as a ".asp".

Believe it or not, things may yet get sillier...

For ages I have told less technical folk (especially SOHO types) asking
for such advice that they should visit www.microsoft.com/security --
following my own advice the other day in the need to check something
out, imagine my surprise when an apparently successful page load
resulted in an entirely blank window...

I guess it is not that surprising now, eh?

As best I can tell, requesting that URI results in what is actually:

http://www.microsoft.com/security/default.asp

being served.

Guess what? That page consists solely of an absolutely minimal set of
HTML tags and the one-line script:

window.location.replace("/security/default.mspx")

intended to redirect script-enabled users to:

http://www.microsoft.com/security/default.mspx

while leaving scriptless visitors staring at a blank page.

The obvious first question is why is the server still configured to
serve default.asp, rather than default.mspx, when asked for
http://www.microsoft.com/security/? Sure, keep a default.asp page with
some kind of redirection in place to handle all those bookmark and link
references that originally included the "default.asp" part of the URI
path, but why leave the server config to treat that as the default page
to serve for that URI? Second, if you must redirect, as above, why do
it purely using client-side script?

....

All this _recent_ script nonsense is clearly antithetical to Billy
Boy's close to 2.5 year old dictate that security must trump featuritis
in MS products and services. Is 28 months not enough time to hammer
into the web designers at MS the basic idea that assuming client-side
scripting is enabled across the the board is both stupid and
antithetical to the company's much vaunted (though seemingly worthless)
"Security Initiative"? The continued appearance of new web pages that
require client-side scripting be enabled for the page to have _any_
utility at all, _especially_ when there are better non-script
alternatives suggests that those who design and provide the most public
face of MS -- its web site -- not only have not yet got the picture,
but have no idea that the frame of reference was changed more than two
years ago...

Don't get me wrong -- folk who want or, <shiver> "need", to see the
pink flying elephant "features" as most welcome to them, along with all
the horrendous security vulnerability exploits that are so much easier
in script-enabled browsers. More power to them -- heck, they ensure we
have a job... But for pity's sake, why are MS' web designers _still_
designing pages that require scripting where simple "submit", "href"
and such other _basic_ HTML concepts will provide the same level of
functionality for the main purpose of "bread and butter" web browsing
-- information presentation???

At the outset of the Security Initiative the skeptics largely said
"it's a marketing ploy", but its defenders said "it will take time for
the real results to be seen". As the weeks turned into months and now
years and little has been seen to have improved (and some very public
things to have gone backwards), it seems increasingly that the skeptics
may have been right...


Regards,

Nick FitzGerald

[Greg Kujawa]

In-Reply-To: <40CB8263.18297.7605685C@localhost>

I have to applaud your specific examples of where Microsoft's aims have been redirected (pun intended) and have become woefully presumptuous. Having worked in web hosting and website development in past lives I would agree that correcting the weblinks wou
ld be a truer solution than just performing all of the sneaky redirects that require scripting to be enabled.

Here's my question. Everyone please feel free to point out its validity as necessary. Why not add www.microsoft.com to your Trusted Sites list and allow this Internet Zone to have Active Scripting function as prompted? Are there cross-site exploits presen
t that even make this a poor solution? This is the interim solution I have in place at my business locations. We have to use Internet Explorer for work-related application requirements. Otherwise I wouldn't switched to something like Mozilla.

In lieu of Microsoft patching the latest round of Secunia announced security holes I am disabling Active Scripting for all Internet Zones but the Trusted Sites Zone. If this isn't the best alternative what is if we *have* to use MSIE?

Anyone??

[Nick FitzGerald]

Greg Kujawa <greg.kujawa@diamondcellar.com> wrote:

<<snip>>
> Here's my question. Everyone please feel free to point out its validity
> as necessary. Why not add www.microsoft.com to your Trusted Sites list

You'd trust them after all that history?

Aside from the very shoddy security history (which shows little real
indication of changing, no matter how many column inches the MS
publicity steam-roller manages to drum up to the contrary), MS is a
"big target" so microsoft.com is more likely to be targeted for attack.

> and allow this Internet Zone to have Active Scripting function as
> prompted? Are there cross-site exploits present that even make this a
> poor solution? This is the interim solution I have in place at my
> business locations. ...

Given IE's history, I'd probably be more worried about _cross ZONE_
security flaws than cross site ones (not that the latter aren't
potentially significant). In fact, cross zone vulns are among the
those MS is slowest to fix and most likely to be only partially fixed,
with trivial exploit variants surfacing after the first patch. Such
attacks _are_ widely used, as many, many weeks of ms-its: protocol
abuse by spammers and adware peddlers recently showed (of course, they
continue with such abuse because there are tons of still-vulnerable
because they have not patched users, but that's not you).

Because the security zone model is so fundamentally broken (arguably
broken by design given its vulnerability history), I am quite reluctant
to give any domain raised privileges by adding it to that zone (and, in
my admittedly self-preservationally paranoid IE configuration, those
"raised" privileges are not even equivalent to the way too liberal
default "Internet zone" settings).

> ... We have to use Internet Explorer for work-related
> application requirements. ...

Utter rubbish!

Anyone who says "we have to use IE because..." is then simply mouthing
some other vendor's security ignorance which boils down to either or
both of:

we [the other vendor] are lazy scumbags who can't be bothered to
learn how to write our programs well

and:

we [the other vendor] don't give a sh*t about our clients' system
security because we are so arrogant as to require our clients to use
products no-one with any security smarts would wish on their worst
enemies

It's not quite exactly the same, but can anyone really see any
fundamental practical difference between the situation:

Supplier X requires us to run Security-bug_Ridden_Web_Browser Y (aka
IE)

and the first "immutable security law":

If a bad guy can persuade you to run his program on your computer
it's not your computer anymore

???

To paraphrase the security law to match this specific situation:

If a supplier can persuade you to run Security-bug_Ridden_Web_
Browser Y on your computer, it's not your computer anymore

Now do you understand?

If a web browser is just a data neutral information display device
(which is what it is supposed to be), it is no-one's business but your
own which browser you choose to use for whatever reason[s]. If you
have suppliers that do not understand that, get better suppliers -- in
the long run you will be helping your current suppliers as well as
yourself...

> ... Otherwise I wouldn't switched to something
> like Mozilla.

I presume you mean "would have"...

> In lieu of Microsoft patching the latest round of Secunia announced
> security holes I am disabling Active Scripting for all Internet Zones
> but the Trusted Sites Zone. If this isn't the best alternative what is
> if we *have* to use MSIE?
>
> Anyone??

Won't help you a scrap. At least one of those vulns is a very nasty
cross zone flaw, whereby the zone-checking part of IE (yet again) is
trivially tricked into seeing a URI as belonging in a more trusted zone
than the "effective URI" (i.e. the one that is actually acted on by the
content parsers, script engines, ActiveX, etc) should be seen to be in.
Recipe for trouble, especially if you add microsoft.com to the TS zone
as it's a good bet that the scumware vendors may well start trying to
abuse this latest vuln by assuming that many folk are probably dim
enough to entrust microsoft.com to the TS zone -- attempted exploits
based on that assumption will outright fail on a huge proportion of
potential victim machines, but likely work on enough to make attempting
it worthwhile (like spam, such folk live quite well off _triflingly
low_ hit rates).


Regards,

Nick FitzGerald