Re: Biometrics

My mistake. Thanks for the corrections. Here is Chris Quirke's, MVP reply
to some of this stuff. He has trouble viewing this newsgroup.


Chris Quirke, MVP replies:


At 10:56 23/7/2008, you wrote:

It would be nice if you could post to the microsoft.public.security
newsgroup where this heated debate is going on in biometrics.

Newsgroups are tricky for me right now :-/

"Steve Riley [MSFT]" wrote:

1. NO ONE KNOWS whether your suggested operating system
has the same vulnerability.

Or different problems with similar impact. Consider the years of "safe" RPC
in NT up until the patch, and the mass exploits shortly thereafter...
for all we
know, folks may have been quietly exploiting that vulnerability for years.

2. ALL software has vulnerabilities, many of which allow attackers to
take control of a system. Establishing good security practices (patch
when we release, install only the services you need, apply the principle
of least privilege to data, and so on) is MORE important than the
particular piece of technology you've chosen to deploy.

Yup - and I'd love to apply the principle of ripping out risk surfaces
that I don't need, but that's hard when they are welded into the OS.

I take Steve's point that a supported and patched code base is more
likely to get defects discovered and fixed, but as a stand-alone user,
I'd feel safer on an OS designed as such, not as a network client -
especially when these networking surfaces are exposed to the Internet.

And the older the software is, the more difficult it is to manage

True

and the more likely it is to get attacked --

Possibly false, if the older OS has shrunk its market share and is
different enough to avoid being cross-exploited by attacks made on
newer and more popular OSs. IOW, much of Win9x's present
safety (in terms of less often being attacked) may be similar to that
for MacOS and Linuxen; it's now a minority OS.

because older software was not written to be centrally-managed
(no group policy and no machine identity in 9x, for instance)

That's relevant to managed, network-centric IT, but that's not where
we live. That mindset is part of our problem, because in our world,
there is NO remote entity who should control our PCs under any
circumstances. The presence of such facilities is needed so pro-IT
can manage network clients, but it's all risk and no benefit to us.

and was not written with resiliency in mind.

The design briefs were different, so we don't expect 9x to be as
stable as NT. It wasn't too bad, in my experience over the years.

Whereas in the past most attacks were targeted at the
operating system, this is no longer true. The majority of
crashes we see now come from third-party software installed
on the box. And in this case, crashes are good:

IKWYM - "Error messages are your friends"...

various features in the operating system (DEP, ASLR, SRP,
and more) have detected that something malicious is
happening, and stop it before the attack succeeds. You
could never do that with an OS as simple as 9x.

There are several factors that come in here, not just how easy it is
to attack a system. Opportunity, i.e. are exploitable surfaces
exposed? How easy or difficult is it for the user to find the malware
files, or their integration points? Can the user get "air superiority"
over the malware, e.g. by tackling it without running it first? IOW,
concerns go beyond infectability or attackability, and on to the ability
to non-destructively get the system back from an infected state.

9x = Internal Safety --- based upon DOS as maintenance
operating system -- lacking in XP and Vista --- no true
maintenance operating system according to Chris Quirke

That's certainly not true as at 2008, if you define maintenance OS
as an OS (that runs arbitrary apps) that can access and manage a
HD installation without running any code from it.

DOS can't work safely over 137G, nor is it effective on NTFS - so that
kills it for Vista, and for anything > 137G.

The best mOS I've used so far, has been Bart, which builds a bootable
CDR environment based on the XP/2003 family (SP2 and later) code
base. This can handle NTFS and Win2000/XP/2003 (not Vista) registry
hives, so that registry-aware tools can act on these hives as if they were
active. It also supports the best range of tools, in my experience, and
can work in 64M RAM. Limitations: Can see USB storage only at boot
time, not on the fly; no firewall; hard to patch beyond SP baselines, and
can't "see" many modern S-ATA hard drive interfaces.

WinPE 2.0 is now available to the public, is based on Vista, and is in
many ways a promising mOS. Compared to Bart, it has better USB
support, allows boot CDR to be ejected and replaced, has built-in
firewall, but requires 512M RAM and fails to run many of the tools
that work in Bart. I find it harder to integrate tools into WinPE than
Bart, and there's no ability to transparently map the HD installation's
registry hives into place for registry-aware tools.

Linux can now natively read NTFS, so qualifies as a mOS too... but
there's no ability to access the HD installation's registry, either in a
transparent manner, or as a crude binding of hives via a Regedit (which
breaks expected registry paths, thus not transparent).


So right now, formally accessing XP and Vista isn't really the problem
that limits post-infection malware management. A bigger limitation is
the quality of the scanners that one can bring to bear via these mOSs.

I find the best mOS-supported solution right now, is XP + Bart. Next
best would be Vista and 9x, both suffering from the inability to run
registry-aware tools against the inactive HD registry hives. Ironically,
I now manage infected 9x PCs by scanning their HDs from Bart :-)

"Steve Riley [MSFT]" wrote:

A standalone computer certainly is secure, and keeps its users safe.
For such a computer will never receive or transmit unwanted software

USB can be a problem, if the OS is stupid enough to clicklessly
autorun code off such storage. That may be more likely in the
newer OSs, which don't have a good track record there.

The value of a networked system increases as the square
of the number of elements in that system.

I don't find that case too compelling :-)

: >> >> Chris's distinction between the Internet and "a network"
: >> >> (presumably private, for Chris doesn't specify) isn't useful

I'd say it's essential, and not "getting" this is a critical safety failure.

Yes, by "network" I do mean "private network", with LANs and
secured WAN (e.g. VPN) in mind. In these network contexts,
membership is limited to trusted entities; the whole thrust of
pro-IT is maintaining those limits, managing identities, and
what these identities are trusted to do.

In contrast, the Internet is a world of strangers. It's meaningless
to prove a particular identity if the user knows nothing about that
identity (and thus has no basis to assess trustworthiness). Only
once you prove an identity that is known, can one think in terms
of networking, rather than generic Internet access.

Yes, it's possible to expose business networks to the Internet,
and to manage user identities and permissions on large networks.
However, it may be a highly-skilled full-time job to do so, and that
too will escalate with the number of systems on the network.

So the value equation that works so well for corporations, works
far less well for end users. That didn't matter to big business in
the old days, but now that end user systems collectively wield
significant bandwidth and computational power, it matters more.

Chris's argument that per-user security "creates artificial
scopes" doesn't reflect reality. On the contrary, _stronger_
per-user (and per-machine) identity and authentication
are critical for allowing the network effect to flourish.

That was a statement, not an argument - IOW, the fact that per-user
scopes are artificial, does not mean they are not worthwhile. It should
perhaps inform as to how reliable they can be expected to be, though.

My point was that the objection that "the difference between data and
code is artificial and blurred" will equally apply to the difference between
user identities, user accounts and login sessions. Both may be seen
as artificial and leaky, but IMO both are worthwhile concepts to design
in and to attempt to enforce.

This has been done fairly intensively for user identity management in
the world of pro-IT, where it is highly relevant. I would argue that we
should do the same for data/code separation and risk management,
particularly in consumerland, where it is more relevant than identity.

How many consumerland infections were caused by identity failures?
How many were caused by the correct user identity triggering code
that did things the user would not have wanted to happen?

When we reach the point where all communications
are in the context of validated identities, carried
in transactions with integrity and confidentiality
protection, between endpoints that mutually
authenticate their identities and their configurations,
then who cares whether the underlying network is
trusted or not?

The point of failure there is not so much the network (though DNS
vulnerabilities may be relevant there) but in the assumption that an
authenticated system acts only within the intentions of the supposed
user of that system. You may really be talking to my PC, but what
it's doing may not represent my will; it may be acting under the direct
control of some other entity, or I (or the system) may have been
spoofed into initiating something I did not want.




"Steve Riley [MSFT]" wrote:

Dan, how in the world have you conflated remote assistance with file
systems? They have zero relationship.

Besides, the presence of a remote assistance capability does not at all
indicate that the underlying operating system is inherently less secure --
just like the absence of such ability does not indicate that the underlying
operating system is inherently more secure. The remote assistance feature:

* is disabled by default
* requires you to enable it before any connections are permitted
* requires you to invite someone else to connect
* encrypts the communications path with 128-bit RC4
* allows you to disconnect the session at will

Using your terminology, these steps provide sufficient "internal safety."
There is no way that someone from anywhere in Microsoft (not just India) can
or would connect to your computer without your knowledge and consent.

Linking back to file systems -- you do understand, of course, that your
FAT-formatted C: drive is accessible to any remote assistance session. Say
you have Windows 98 on that drive. A malicious remote assistance user could
easily replace those files and -- if you weren't watching -- you'd have no
idea until you next booted it. Compare this Windows Vista: if someone
replaced parts of the non-booted operating system, then next time it's
booted, Windows integrity protection and system file protection alerts you
to this; the system either refuses to boot or reverts to its original state
(depending on what was maliciously overwritten). Again, Vista's "internal
safety" is vastly improved over that of any previous version of Windows.

I don't know what else I can say to help you understand.

--
Steve Riley
steve.riley@xxxxxxxxxxxxx
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com



"Dan" <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2EB67198-4ACB-4437-A17C-3CA42D5C342C@xxxxxxxxxxxxxxxx
1. True

2. That is true but XP and even Vista are totally focused on external
security. Can Microsoft remotely work on a Microsoft Windows 98 Second
Edition computer via India like Microsoft can work on a Windows XP
Professional computer? Microsoft has done remote access work on the XP
side
of my dual-boot computer which is in NTFS. My computer has a Western
Digital
Hard Drive in Fat 32 on C: and a separate hard drive on D: with Windows XP
Professional.

3. I have tried out Ubuntu Linux within a Windows environment within XP
Professional. I have run Windows Virtual PC 2007 within Windows XP
Professional. It is great but it does not fully meet my needs as a
consumer.
Consumers want to play games. My friend Chris from camp is going to build
a
98 Second Edition computer with my old motherboard. He wants to play old
dos
games that he enjoys. The nice thing about 98 Second Edition is that you
can
exit to MS-DOS mode. This allows gamers to play games. It is all in the
Microsoft articles about compatibility.

http://www.aumha.org/win4/a/resource.php

http://support.microsoft.com/?kbid=146418

---------------------------------------------------------------------------------

"Steve Riley [MSFT]" wrote:

You are asserting that one single vulnerability allows "military and top
secrets to be leaked" and thus requires the use of some other operating
system. You simply cannot make this assertion, for two reasons.

1. NO ONE KNOWS whether your suggested operating system has the same
vulnerability.

2. ALL software has vulnerabilities, many of which allow attackers to
take
control of a system. Establishing good security practices (patch when we
release, install only the services you need, apply the principle of least
privilege to data, and so on) is MORE important than the particular piece
of
technology you've chosen to deploy. And the older the software is, the
more
difficult it is to manage and the more likely it is to get attacked --
because older software was not written to be centrally-managed (no group
policy and no machine identity in 9x, for instance) and was not written
with
resiliency in mind.

And this talk of "internal safety" regarding 9x is really nonsensical.
Vista
and even XP+SP3 are FAR more difficult to attack than 9x was. We at
Microsoft have the benefit of about 10 years of historical data from
Watson
reports (online crash analysis, Windows error reporting). We can divine a
lot of information about attacks from this data. Whereas in the past most
attacks were targeted at the operating system, this is no longer true.
The
majority of crashes we see now come from third-party software installed
on
the box. And in this case, crashes are good: various features in the
operating system (DEP, ASLR, SRP, and more) have detected that something
malicious is happening, and stop it before the attack succeeds. You could
never do that with an OS as simple as 9x.


--
Steve Riley
steve.riley@xxxxxxxxxxxxx
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com



"Dan" <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1D0AF19C-B164-450F-92D3-96F6E1E9FDA6@xxxxxxxxxxxxxxxx
I see your point Steve but US-Cert maintains that all NT source code is
vulnerable thus my point being valid about having 98 Second Edition
machines
within a network for internal safety reasons and potentially to act as
gateways. How can we allow our military and top secrets to be leaked.
Please see the United States Computer Readiness Team at the Department
of
Homeland Security and so you can see how I am getting at the true value
of
a
source code that is flexible enough to offer external security,
internal
safety, and more. Thus we have a source code matrix as presented
below.
I
am not skilled enough to write the code for this yet but I bet
Microsoft
and
others are.

--------------------------------------------------------------------------

NT= New Technology --- outer defense network

9x = Internal Safety --- based upon DOS as maintenance operating
system --
lacking in XP and Vista --- no true maintenance operating system
according
to
Chris Quirke, MVP --- Vista is indeed great on security issues but
still
lacks in compatibility as the FAA has mentioned only using Windows 2000
(which I like as well --- totally old-school reminds me of Windows 98
Second
Edition) as well XP machines (which are good but too vulnerable in this
day
and age due to the large surface area created by too many services and
not
having strong enough default settings within Internet Explorer --
another
reason to separate the browser from Windows like the Justice Department
mentioned rightly in the 1998 case although Apple should be
investigated
now
for the practice of tying Quick time with Itunes and I feel this
practice
of
tying software must be banned for safety and security reasons in the
future.)

Unix/Linux/Mozilla/etc. --- third party programs and open source
technologies mingling as one with closed proprietary software which is
protected by IP. Thank you for continuing this discussion.


-------------------------------------------from us
cert------------------------

Vulnerability Note VU#800113
Multiple DNS implementations vulnerable to cache poisoning
Overview
Deficiencies in the DNS protocol and common DNS implementations
facilitate
DNS cache poisoning attacks.


http://www.kb.cert.org/vuls/id/800113

http://www.kb.cert.org/vuls/id/MIMG-7DPJ7W (Microsoft NT but not 9x
vulnerable)


http://www.kb.cert.org/vuls/id/MIMG-7ECLCY (Ubuntu vulnerable)

http://www.kb.cert.org/vuls/id/MIMG-7ECL5Z (Apple unknown whether
vulnerable)

I am sure you know see that 3 dans --- 2 on that website and myself
another
Dan have helped bring this issue to light about how critical it is ---
kind
of boggles the mind doesn't it ---- good reason to bring 98 Second
Edition
and/or another variant 9x/NT/Unix source code --- on-line --- Microsoft
is
the only one that has the resources to do this and the whole world now
needs
your help -- Thank You for seeing the Light of our current situation
within
the Defense Network.

----------------------------------------------------------------------------



"Steve Riley [MSFT]" wrote:

A standalone telephone certainly is secure, and keeps its users safe.
For
such a phone will never receive or transmit unwanted conversations,
and
the
users of such phones will never be bothered with advertisements,
thoughts
that challenge their perceptions, or interesting and surprising
opportunities.

A standalone computer certainly is secure, and keeps its users safe.
For
such a computer will never receive or transmit unwanted software, and
the
users of such computers will never be bothered with advertisements,
thoughts
that challenge their perceptions, or interesting and surprising
opportunities.

No risk = no reward.

The value of a networked system increases as the square of the number
of
elements in that system. A single system has a value of 1^2=1; a
two-element
network has a value of 2^2=4; a three element network has a value of
3^2=9;
and so on. (Bob Metcalfe, "It's all in your head," Forbes Magazine, 7
May
2007: http://www.forbes.com/forbes/2007/0507/052.html.)

Chris's distinction between the Internet and "a network" (presumably
private, for Chris doesn't specify) isn't useful today. The network
effect
is clearly evident on the Internet; I'd argue that in a private
network,
the
network effect is diminished. Why else would we all be rushing
headlong
into
the eventual recognition that private corpnets truly belong on the
Internet,
and that continuing to make the distinction means a loss of real
business
value? (Scott Charney, "Creating a more trusted Internet,"
http://download.microsoft.com/download/2/f/7/2f752ae4-7e1d-4dbd-b75a-aa2dcb0eff5b/End_to_End_Trust_Statement_of_Purpose_Charney.pdf;
Steve Riley, "Directly connect your corpnet with IPsec and IPv6,"
http://blogs.technet.com/steriley/archive/2008/06/25/directly-connect-to-your-corpnet-with-ipsec-and-ipv6.aspx.)

I quote our own materials here as evidence of the demand from
forward-thinking customers that the industry envision new practices
and
develop new technologies that allow for the full realization of the
network
effect. Chris's argument that per-user security "creates artificial
scopes"
doesn't reflect reality. On the contrary, _stronger_ per-user (and
per-machine) identity and authentication are critical for allowing the
network effect to flourish. Indeed, the lack of strong identity and
authentication has been a hindrance, and that's why you see
technologies
like smart cards and TPM chips becoming more common. When we reach the
point
where all communications are in the context of validated identities,
carried
in transactions with integrity and confidentiality protection, between
endpoints that mutually authenticate their identities and their
configurations, then who cares whether the underlying network is
trusted
or
not?

--
Steve Riley
steve.riley@xxxxxxxxxxxxx
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com



.

Relevant Pages

  • RE: Serious Security Issue in Windows XP SP2s Firewall
    ... option to limit it to your internal network IP addresses. ... Serious Security Issue in Windows XP SP2's Firewall ... > connect to the Internet via dial-up or ISDN. ... > the dial-up connection as soon as you were connected to the Internet. ...
    (Focus-Microsoft)
  • Fw: Serious Security Issue in Windows XP SP2s Firewall
    ... Serious Security Issue in Windows XP SP2's Firewall ... > connect to the Internet via dial-up or ISDN. ... > network at home: Often, we did not even encounter password protection. ... > the dial-up connection as soon as you were connected to the Internet. ...
    (Focus-Microsoft)
  • Serious Security Issue in Windows XP SP2s Firewall
    ... PC-WELT discovers and fixes serious security issue in Windows XP SP2 ... Internet via dial-up or ISDN. ... Internet Connection Sharing of the PC ... network at home: Often, we did not even encounter password protection. ...
    (Bugtraq)
  • Re: Finding multi-homed, internet connected, systems as potential point-of-entry.
    ... It uses ICMP and may or may not work depending on how the local network is set up. ... that are able to directly connect to the internet ... -Detect for the response of this message on the spoofed address at the ... Cross site scripting and other web attacks before hackers do! ...
    (Pen-Test)
  • Re: Big hole??
    ... supposedly safe SP2 for Windows XP invites any Internet ... Connection Sharing of the PC has to be disabled. ... visible in their network at home: ...
    (microsoft.public.windowsxp.general)