Re: OpenVMS - When downtime is not an option
- From: david20@xxxxxxxxxxxxxxxx
- Date: Thu, 5 Jul 2007 16:07:04 +0000 (UTC)
In article <6I2dnYpHVtQddhHbnZ2dnUVZ_qyjnZ2d@xxxxxxxxxxxxxxxxxxxxxxxx>, Bill Todd <billtodd@xxxxxxxxxxxxx> writes:
david20@xxxxxxxxxxxxxxxx wrote:
In article <39qdnSc41MVyvxHbnZ2dnUVZ_ompnZ2d@xxxxxxxxxxxxxxxxxxxxxxxx>, Bill Todd <billtodd@xxxxxxxxxxxxx> writes:
david20@xxxxxxxxxxxxxxxx wrote:
In article <h8SdnWZlQ7mWVRfbnZ2dnUVZ_vmqnZ2d@xxxxxxxxxxxxxxxxxxxxxxxx>, Bill Todd <billtodd@xxxxxxxxxxxxx> writes:As I'm starting to get tired of saying, *exactly* what it seems to be.
Main, Kerry wrote:What is this "IF" ?
....
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.
From http://www.microsoft.com/technet/security/bulletin/ms07-026.mspxObviously you're not very familiar with Microsoft's exposure descriptions.
"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.
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.
That's how I interpret its statement "An attacker could then install
programs; view, change, or delete data; or create new accounts with full
user rights" (i.e., I think the last four words distribute over all the
elements in the preceding list - and note in any event that they talk
about *user* rights rather than *administrator* rights).
Sorry
"; or create new accounts with full user rights" is obviously talking about an
attacker being able to create fully privileged user accounts.
It is just expanding on the types of activities that an attacker could
carry out once they had gained complete control of the system.
Since one of the list items "view, change, or delete data" is itself a list of
actions which can be performed on data semi-colons are used to separate the
list items. The semi-colon is a powerful punctuation mark which is either used
in complicated lists such as this or to separate closely related but
independent clauses.
Neither of those functions would allow the phrase "with full user rights" to
distribute over all the items in the list.
To distribute those words over the list you would need some additional
punctuation such as
"
An attacker could then install programs; view, change, or delete data; or
create new accounts: with full user rights.
"
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.
See above (though the phrasing is fuzzy enough to admit to varying
interpretation).
You are simply misinterpreting the phrasing.
What I had in mind was the more common phrasing reflected in MS07-035,
where it says "An attacker who successfully exploited this vulnerability
could take complete control of an affected system" but then clarifies
that as follows: "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."
I agree Microsoft use this, and the similar phrasing I mentioned above, when
that is indeed the case. However in this and other cases they do not use that
phrasing. Instead they clarify that the user could
"install programs; view, change, or delete data; or create new accounts with
full user rights".
David Webb
Security team leader
CCSS
Middlesex University
David Webb
Security team leader
CCSS
Middlesex University
.
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
In the example I provided immediately above (which uses nearly identical
phrasing) 'could' is clearly used exactly as I described it.
- bill
- Follow-Ups:
- 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
- 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
- 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: OpenVMS - When downtime is not an option
- Next by Date: Re: What happen to the Deathrow cluster
- 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
|