[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44A158E9.3010206@gmail.com>
Date: Tue Jun 27 17:11:13 2006
From: jftucker at gmail.com (James Tucker)
Subject: Microsoft's Real Test with Vista
is Vulnerabilities
Brate Sanders wrote:
>Honestly, do you believe MS would care too much about security in Windows or their applications? If they did, would they come out with the One Live subscription based solution to protect against their design/implementation vulnerabilities? Once One Live subscription becomes more wide spread you can expect press releases like, if you are using One Live this vulnerability will not affect you. If not we are working on a solution for your problem, which may be available in your next monthly patch cycle.
>
>
Not interested in a mass discussion, however you clearly know nothing
about the difference between a 'security product' and an 'operating
system' and it's related libraries. Your rant here is like a *nix user
claiming they will never ever need an anti-virus program. I suppose you
shouldn't really need an IDS either?
Where did the OneCare application set come from? Why is it coded the way
it is? Why is this method of scanning condusive to prevention of
otherwise available exploits on a local machine? Is it therefore
reasonable that something may be prevented by a third party application
even if it's not created by a third party? Is this unusual in non-MS worlds?
>Microsoft has tried multiple times in the past to come out with a subscription model for Windows, which has failed every time. So now they have another oppurtunity to get into the subscription based model. They may even give away Windows OS for free and just charge you for the OneLive solution, since it is a better business model any way you consider it.
>
>
If you've been testing Vista Beta 2, and not being overly unnecessarily
paranoid (despite the clearly written privacy policies and so on) then
you'd have probably noticed that application error reports are even
while in beta, being looked at directly by humans. The perfect example
being the customised responses I have had to several application
failures, one of which provided me with a suitable fix and added a bug
ticket for the next release. This is completely seperate from the Live
services.
>So if they can earn more from the subscription based security solution where is the incentive to make the OS more secure? Eventually they are a corporation aimed at maximizing their shareholder value.
>
>
All US coroporations are bound BY LAW to do as you suggest there.
Campaign against US Law if you have an issue with that. If you fight a
battle on the wrong field you'll never meet your enemy.
With regard to incentive to secure the OS, the OS is still being
secured, as it has been with XP, the reason the distinction exists can
be clearly seen by the following example:
A customer reports that the elevate priviliges request is exploitable by
providing it with excess data.
The function filter system in a random system defender app can filter
this immediately, thus an update for the FILTER system is released
immediately, all 'defender' based machines are now secured.
The core function change requires the arguments of the function to be
changed, the type of one argument is altered - this requires a wrapper
function, and FULL common usage bounds checking for ALL applications
using that function. - The easiest way to do this is to collect
demographics to see how often it is used, easiest to collect through the
function filter.
Testing for the above CORE OS CHANGE is going to take some time, in
order to maintain backwards compatibility, including supporting some odd
applications where programmers decided to use the 'exploit' for
productive purposes. To change this immediately without providing a
wrapper or checking common usage is likely to break legitimate software,
to prevent the use of one piece of malware. In terms of productivity in
the wild, such things are only destructive - see professional gentoo
deployments for examples.
>Brate Sanders
>
>
The man who should clearly be writing YOUR update policies.
Powered by blists - more mailing lists