Re: Is Windows inherently more vulnerable to malware attacks than OS X?

"Chris Clement" <chris.clement@xxxxxxx> wrote in message
news:1156358926.151645.32700@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Answer: Yes

Well, nobody has been able to make a serious
case for this claim. Maccies like to claim it,
but that's because it makes 'em feel better.

[snip- Describes Buffer Overflow]

Bear in mind that what you've described
is your basic buffer overflow exploit, not
some remarkable new breakthrough in
hackery.

[snip]
· All Windows background processes/daemons are spawned from a single
hyper-privileged process and referred to as services.

Calling them services is a problem? :D

· By default, Windows launches all services with SYSTEM-level
privileges.

No. Each service must have a user account specified;
System is just one possibility.

· SYSTEM is a pseudo-user (LocalSystem) that trumps Administrator
(like UNIX's root) in privileges. SYSTEM cannot be used to log in, but
it also has no password, no login script, no shell and no environment,
therefore
· The activity of SYSTEM is next to impossible to control or log.

Are you saying the NT would be *more secure* if
end users logged in as SYSTEM? More controllable?
More loggable?

This is not the conventional view. Notice that Apple
has disabled 'root' by default on Mac OS X, specifically
because interactive logins on such an account are
widely considered a bad security practice.

· Most of the code running on any Windows system at a given time is
related to services, most or all of which run with SYSTEM privileges,
therefore

Certainly not all, but many services do run as SYSTEM.

This is because this is the normal way to run privileged
code on Windows; on Unix you'd have setuid-root
programs instead. On OS X you have authorization
services granting root access.

Neither OS X nor XP have a lot to be proud of
in this regard; both resort to highly privileged
processes at the drop of a hat. What is different is
the machinery used to generate the privileged
process.

What I can say in XP's defense is this: while it isn't
used as much as it should be, the machinery for
fine-grained privileges does exist. When you build
your own services, you don't need to use SYSTEM.

On Mac OS X, it is root or nothing. "Admin"
accounts are simply ordinary accounts permitted
to use sudo, which grants root access.

OS X has, in this regard, inherited one of the
famous security flaws of Unix.

· Successful infection of running Windows software carries a good
chance of access to SYSTEM privileges.

I do not think chance has much to do with it;
hackers naturally target such services.

· Windows buries most privileged software, service executables and
configuration files in a single, unstructured massive directory
(SYSTEM32) that is frequently used by third parties. Windows will
notify you on an attempt to overwrite one of its own system files
stored here, but does not try to protect privileged software.

Yes, it does. If any windows component is replaced by
user software, Windows puts the original back.

This is inelegant compared to just locking down the
directory, but it works and is much more backward
compatible.

· Microsoft does not sign or document the name and purpose of the
files it places in SYSTEM32.

Microsoft does document some of this stuff, but not
in the online help; it is in MSDN. But not everything
in there is documented.

· Windows has no equivalent to OS X's bill of materials, so it cannot
validate permissions, dates and checksums of system and third-party
software.

Yes, it does. Windows Installer stashes copies of
the .msi files for installed products, and it autorepairs
them if damanged, when you start them.

· Windows requires that users log in with administrative privileges
to install software, which causes many to use privileged accounts for
day-to-day usage.

This is true, but it is also true of Mac OS X. Nobody
has a good answer to this problem yet.

· Windows requires extraordinary effort to extract the path to, and
the files and TCP/UDP ports opened by, running services, and to certify
that they are valid.

I am not too clear on what you are trying to do
here. If you think you can detect a rootkit
in this way, I would not help for too much.

If there were an easy to use tool for this, rootkits
would subvert it as a matter of course.

· Microsoft made it easy for commercial applications to refuse a
debugger's attempt to attach to a process or thread. Attackers use this
same mechanism to cloak malware. A privileged user must never be denied
access to a debugger on any system. My right to track down malware on
my computers trumps vendors' interests in preventing piracy or
reverse-engineering. Maintaining that right is one of the reasons that
open source commercial OS kernels are so vital.

MS does this because if you can attach a debugger to an
app, you can subvert it; this is therefore an obvious malware
vector. So they secure it.

· Access to the massive, arcane, nearly unstructured,
non-human-readable Windows Registry, which was to be obsolete by now,
remains the only resource a Windows attacker needs to analyze and
control a Windows system.

This is just a generic whine; it has nothing to do with
malware at all.

· Another trick that attackers learned from Microsoft is that
Registry entries can be made read-only even to the Administrator, so
you can find an exploit and be blocked from disarming it.

This is no different from a filesystem; and an
adminstrator can still take ownership. But, if your
system has been rooted, then any mechanism,
even this, can be subverted.

Once you are owned, you are owned.

· Malicious code or data can be concealed in NTFS files' secondary
streams. These are similar to HFS forks, but so few would think to look
at these.

Malicious code can be concealed in all sorts of places;
this really isn't very interesting.

· One of the strongest tools that Microsoft has to protect users from
malware is Access Control Lists (ACLs), but standard tools make ACLs
difficult to employ, so most opt for NTFS's inadequate standard access
rights.

ACLs are of limited value for this, in practice, because
users need to be able to access their own files, install
software, and so on. The ACLs can't be too tight.

Why this can't happen under OS X:

· OS X has no user account with privileges exceeding root.

NT hasn't got any account- user or otherwise- that is
even as privileged as root. Not even SYSTEM.

Root is an account for which security checks are
disabled; SYSTEM is just highly privileged.

You've got this one backwards.

· Maximum privilege is extended only to descendants of process ID 1
(init or Darwin's launchd), a role that is rarely used and closely
scrutinized.

Absolutely all processes in Unix are descendanes of
init, so this doesn't exactly help very much.

· Unlike services.exe, launchd executes daemons and scheduled
commands in a shell that's subject to login scripts, environment
variables, resource limits, auditing and all security features of
Darwin/OS X.

Needless to say, NT services are also subject to the
security features of NT. These do not depend on
environment various or login scripts, but quotas,
auditing, and all that is in force.

· Apple's daemons have man pages, and third parties are duty-bound to
provide the same. Admins also expect to be able to run daemons, with
verbose reporting, in a shell for testing.

I do not quite see what you mean by "duty bound"
most Mac apps do not include man pages, so
I'd be surprised if a 3rd party daemon included
such a thing.

I do not see what running a daemon from a shell
does to help security.

· OS X Man pages document daemons' file dependencies, so
administrators can easily rework file permissions to match
daemons' reduced privileges.

I've never seen a man page like that. Do these man pages
also assert that new versions of OS X won't change
the list of files accessed by daemons?

· Launchd can tripwire directories so that if they're altered
unexpectedly, launchd triggers a response.

This seems like just some random feature to me.

· If an attacker takes over a local or remote console, any effort to
install software or alter significant system settings cannot proceed
without entering the administrator's user name and password, even if
the console is already logged in as a privileged user. In other words,
even having privileges doesn't ensure that even an inside hacker can
arrange to keep them.

Actually, no. If malware manages to get running on your
local desktop, it can just wait for you to enter your credentials,
and then hijack them.

I haven't verified this, but I suspect this will work from
a remote desktop too, as long as the console users has
the same user-id.

· OS X has a single console and a single system log, both in plain
text.

That is to say, it has two logs: the console and the system log.

NT has its centralized event log, of course.

· OS X's nearest equivalent to the Registry is Netinfo, but this
requires authentication for modification. In later releases of OS X, it
is fairly sparse.

Netinfo is not, as far as I can see, much like
the registry.

· Applications have their own per-user and system-wide properties
files, private Registries if you like, stored in human-readable files
in standard locations.

Those are no more or less human readable than the
registry. And this has nothing to do with security,
either.

· Every installed file is traceable to a bill of materials that can
verify that the file is meant to exist, and that it and all of its
dependencies match their original checksums. Mac users, back up
and protect your Receipts folder!

You mentioned this. But receipts only work if you use the
Apple installer: and some Mac products are shipped as
'naked bundles'. No receipts for these guys.

· The directories used to hold OS X's privileged system executables
are sacred. Anything new that pops up there is immediately suspect.

Sacred?

· OS X does not require that a user be logged in as an administrator
to install software. The user or someone aiding the install needs to
know the name and password of a local administrative user to complete
the install. On a network, most software is installed using Remote
Desktop, an inexpensive Systems Management Server-like console.

This is a major security flaw: all installers demand the username
and password. You have but to trick a user into trying to
install your (malicious) software, and they will, as a matter of
course, give you their password.

· The UNIX/POSIX API, standard command-line tools and open source
tools leave malware unable to hide from a competent OS X administrator.
It takes a new UNIX programmer longer to choose an editor than it does
to write a console app that walks the process tree listing privileged
processes. Finding the owners of open TCP/UDP ports or open files is
similarly trivial. The "system" is not opaque.

Er, no. Once a hacker has penetrated your system, he simply
installs a rootkit, which modifies these tools so they no
longer report accurately.

Once you are owned, you are owned.

· Basic OS X features can be put to use to make life miserable for
malware. For example, Windows' hackable restore points are done better
by OS X's ability to create encrypted, read-only disk images. They're
simpler than archives, and you can mount them as volumes anywhere in
your file hierarchy.

This is very silly. Hacking restore points is pointless;
just hack the actual system instead.

· Likewise, OS X Server will image any Mac client or server's local
drives and maintain safe copies that can be used not only for
restoration, but which can be booted from to guarantee that there's no
trace of infection.

Why can these not be infected themselves?

· When erase-and-reinstall is the only way to be sure, OS X Server
automates it. It can safely capture the affected Mac's active drives
before having that Mac boot from the fresh install image.

Windows also has reinstall features, but the value of
this is limited in the face of serious malware. You have
to really nuke and pave to be sure.

So, after all this, do I have enough to judge Windows inherently more
vulnerable to severe malware than OS X? I do.

You've made a better effort than is usualy at justifying
this, but I don't think you've made a convincing case;
you've got a number of errors in there, and Windows and
OS X are actually a lot more similar than you've implied.

[snip]


.

Relevant Pages

  • Re: Anyone Have This Problem?
    ... I am running Windows XP on a DELL inspiron notebook. ... Internet Security/Anti-virus updates). ... > which contains the bridge-x malware installer. ... > then it is best to get some qualified help to make another clean install ...
    (comp.security.firewalls)
  • Re: WindowsUpdate_80244019 Help
    ... windows live oncare has disabled windows defender, ... IF no malware is detected, ... we'll recommend a tool that will install ... Is that entry in HOSTS, ...
    (microsoft.public.windowsupdate)
  • Re: WindowsUpdate_80244019 Help
    ... windows live oncare has disabled windows defender, ... IF no malware is detected, ... we'll recommend a tool that will install ... Is that entry in HOSTS, ...
    (microsoft.public.windowsupdate)
  • Re: Anyone know how to get rid of latest cool Web hijack?
    ... >> know if i find a cure, but it's looking like total windows reinstall ... > Before you try to remove spyware using any of the programs below, download ... > The process of removing certain malware may kill your internet connection. ... > install malware) Keep it UPDATED. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: How good is Comodo Internet Security?
    ... defaults (like, don't work with admin/root privileges, shut down ... services you don't want to provide, etc.), even Windows is reasonably ... Firewalls can reliably filter inbound traffic. ... Once malware is executed on your system with admin ...
    (comp.security.firewalls)