lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ