Re: OpenVMS - When downtime is not an option
- From: david20@xxxxxxxxxxxxxxxx
- Date: Thu, 5 Jul 2007 11:57:48 +0000 (UTC)
In article <39qdnSc41MVyvxHbnZ2dnUVZ_ompnZ2d@xxxxxxxxxxxxxxxxxxxxxxxx>, Bill Todd <billtodd@xxxxxxxxxxxxx> writes:
david20@xxxxxxxxxxxxxxxx wrote:
In article <h8SdnWZlQ7mWVRfbnZ2dnUVZ_vmqnZ2d@xxxxxxxxxxxxxxxxxxxxxxxx>, Bill Todd <billtodd@xxxxxxxxxxxxx> writes:
Main, Kerry wrote:
....
If the design and/or architecture of the OS platform allows anClearly, that would be an OS bug (or at least a serious design flaw, if
application bug to provide access to protected data and/or provides
elevated rights on the system, does sit matter if it is an application
or kernel OS issue?
indeed it were intentional rather than inadvertent) - *if* it had been
the case in this instance.
It was not: the bugs *only* affected Exchange Server. If Exchange
Server was designed such that it had to execute in a privileged
environment (such that once compromised itself it could compromise other
parts of the system as you describe above), rather than designed
modularly such that at most a few critical parts of it might require
privilege (certainly not including the parsing functions that these bugs
affected) and the rest could run unprivileged, that was an *Exchange
Server* design flaw, not a Windows flaw.
What is this "IF" ?
As I'm starting to get tired of saying, *exactly* what it seems to be.
From http://www.microsoft.com/technet/security/bulletin/ms07-026.mspx
"An attacker who successfully exploited this vulnerability could take
complete control of the affected system. An attacker could then install
programs; view, change or delete data; or create new accounts with full user
rights"
Obviously this means that the codepath executed by the bug must run at a high
privilege level.
Obviously you're not very familiar with Microsoft's exposure descriptions.
Microsoft *always* uses this phrase (which if you read it more carefully
says 'could', not 'can') whenever it *may* be possible that the
execution environment is privileged, very frequently following it (as
indeed it does in this case) with the clarification that what *really*
happens is that the attacker gains the privilege of the applicable
execution environment, whatever that privilege level may be.
Please quote the section in MS07-026 which provides the above clarification
for the MIME Decoding Vulnerability since I cannot see it anywhere.
Microsoft often does say that the exposure only gives the privilege that the
application is running under
(For instance for the MS07-026 OWA Script injection vulnerability it says
"or take any action that the user could take within the context of the OWA
session."
However the more usual formulation is as in MS07-017 for the Windows animated
cursor remote execution vulnerability
"
an attacker who successfully exploited this vulnerability could gain the same
user rights as the local user. Users whose accounts are configured to have
fewer user rights on the system could be less impacted than users who operate
with administrative user rights
"
)
but I see nothing like that for the Mime decoding vulnerability.
Could is used here as the past simple of CAN (since the preceding phrase
"An attacker who successfully exploited this vulnerability" is assumed to have
already happened by the subsequent phrase )
See
http://dictionary.cambridge.org/define.asp?key=17507&dict=CALD
Whether that is because Exchange is running with higher
privileges than it really needs because of bad design and implementation or
whether it is doing something which requires it to have high privileges at that
point in time is not something easily judged without access to the design
documents and/or source of Exchange.
Are you seriously suggesting that parsing the contents of email requires
privilege? Sheesh!
If as you seem to believe it is bad design and implementation in Exchange
causing it to run at higher privileges than needed then it is down to those
designing and programming Exchange at Microsoft. However Exchange is a
Microsoft product and those same designers and programmers have probably also
worked on the OS code during their careers and have had their code reviewed
by the same quality control people.
Now you're getting outright ridiculous: guilt by association, rather
than guilt by evidence.
No just setting out the possibilities.
You're usually one of the more competent contributors here - it would be
nice to see your observations return to that level.
David Webb
Security team leader
CCSS
Middlesex University
- bill.
- Follow-Ups:
- Re: OpenVMS - When downtime is not an option
- From: Bill Todd
- Re: OpenVMS - When downtime is not an option
- References:
- RE: OpenVMS - When downtime is not an option
- From: Main, Kerry
- Re: OpenVMS - When downtime is not an option
- From: Bill Todd
- Re: OpenVMS - When downtime is not an option
- From: david20
- Re: OpenVMS - When downtime is not an option
- From: Bill Todd
- RE: OpenVMS - When downtime is not an option
- Prev by Date: RE: Top ten dead or dying computer skills (guess what's NOT on the list!) list!) list!)
- Next by Date: active/active MSA1000 firmware with DS-KGPSA-DA ?
- Previous by thread: Re: OpenVMS - When downtime is not an option
- Next by thread: Re: OpenVMS - When downtime is not an option
- Index(es):
Relevant Pages
|