Re: So leaky that a $4 billion industry was built to protect it

On Sunday 02 July 2006 08:01 pm, cquirke (MVP Windows shell/user) had this
to say in microsoft.public.windowsxp.general:

On Sun, 02 Jul 2006 16:00:56 -0700, NoStop <nostop@xxxxxxxxxx> wrote:
On Sunday 02 July 2006 01:17 pm, cquirke (MVP Windows shell/user)
On Sat, 24 Jun 2006 11:38:48 -0700, NoStop <nostop@xxxxxxxxxx> wrote:

http://www.emailbattles.com/archive/battles/security_aaeajhghdi_jg/

What a moronic article! (yes, I'll explain why I say that...)
<snip> for brevity.

:-)

The very use of the mean-nothing word "open" is an indication that MS
has dumbed down the UI to the point that it is no longer possible for
newbies to practice "safe hex".

OTOH, is *NIX any better there? AFAIK, *NIX disregards file name
extensions altogether, and routinely names raw code files without any
extension at all. How does a Linux user predict what "opening" an
unknown file will do, if no type info is displayed?

The file has to be marked as executable by the user. Opening any file,
including a so-called executable file will only "run" that program if the
file was first marked through its permissions as executable and who has
permission to execute it.

OK, now for the big question: Are those permissions settings clearly
and unambiguously visible to the user?

Of course. A long directory listing shows the permissions next to each file.
As an example:

rw-rw-r--

The owner of the file can read and write to the file. Other users who are
members of the same group as the owner can read and write to the file. All
others can only read the file. (ie. can't overwrite or delete the file).
The file cannot be "executed" or "run".

Another example:

rwxrwxr-x

The owner can read and write and execute the file. Others belonging to the
same group can do the same. All other users can read the file or execute
the file. (ie. others can't delete the file)



"Yes, if the user does X, Y and Z to query the permissions" is not a
satisfactory answer. A user should be able to predict the possible
impact that "opening" a file can have just by looking at the name and
icon, and the file should not be able to act contrary to the info
shown. It would also be better if the user could automatically think
in terms of "view" vs. "run", knowing that situations where it would
be safe to view data may be unsafe to run code.

Data and code are different beasts. A data file cannot be executed, even if
one was going to set its permission as executable. :-)

On top of this, unlike Windoze, *NIX is designed so that the kernel space
and the user space are totally separate. Some misbehaving application
running in the user space cannot impact or harm the kernel space in any
way. This is one of the main reasons that virus writers haven't been able
to create malware that can bring down a *NIX system, like they can with a
Windoze system where there is no separation between the kernel space and
the user space.

Tell me more about the nature of this "separation"?


The two run in different parts of memory. A buffer overflow in the user
space cannot impact that part of memory that the kernel runs in.

Should a *NIX user decide to make a malware application
(virus, trojan, etc) executable and run same, it cannot impact the system
beyond the user's space. To do any real damage to the operating system as
a whole, the root user would need to run the application.

Oh, OK; this is similar to the "limited user rights" concept. It's
not really a solution for the user's requirements, though I can see
how it can reduce software support calls, because users (and thus the
processes that run with their rights) invariably have the right to
alter (thus overwrite with trash) their own data.

Not so with *NIX as every process is controlled by an appropriate user. So
for example, say you are running a web server on *NIX. The user "apache"
becomes the user on the system that responds to requests and sends them out
to a client. The user "apache" has no rights to overwrite files in the /etc
directory where pretty much most of the system's configurations files lay.
No matter what scripts might be thrown at the web browser, they can't
impact these config files because they are running as a user without
permission to write or execute files outside of it's designated directories
that it owns. Windoze on the other hand doesn't have this kind of security.
Scripkiddies can send a request the web server and that web server can get
into areas of the system and do damage. Happens all the time.

The same thing applies if you are a user. You have rights to your home
directory. But you can't go into the /etc directory and delete or alter
files there. So even if your space gets a virus, that virus can only do
damage within your space and cannot get access to the important system
files that could bring down the o/s. Windoze on the other hand ... any user
can write/delete almost anything on the system. Any software when installed
can write to anywhere in the registry.


*NIX is ahead there, because the *NIX software community has been
familiar with that concept for ages.

*NIX was designed from the ground up as a server/client operating system and
a multiuser operating system. Windoze is not.

MS can develop an elegant
implimentation of lowered user rights, but it's culturally seen as a
new-fangled retro-fit by app developers used to MS OSs.

Believe me, there's a LOT of discussion on this, typically going "Why
does dumb-ass game X or accounting application Y require the user to
have admin rights in order to run???" Contrary to popular belief,
vendors often ignore the dictates (OK, "strong recommendations") from
MS when it suits them, and often the platform is poorer for it...
- hardware "XP" device drivers that are STILL unsigned
- printers that don't work via PnP, only via their Setup.exe
- end-user apps that require admin rights
- apps that smash all actions for file types to their own "open"
Eeewww.

Windoze by default sets up new users as having admin rights when first
installed. This is crazy, and contributes to the major insecurity of a
Windoze box. An admin with windows has to specifically go out of his/her
way to secure the box and try and keep ordinary users away from sensitive
o/s files. Even then, a virus can do extreme damage to the point of
breaking the o/s. Can't happen on a Linux system.


Specifically (apropos the article cited above) I'd say the impact of
malware on Microsoft is mainly negative. It significantly boosts the
cost of post-release development and support (remember, patches and
support calls related to malware are free) and provides the biggest
percieved reason to move away from Microsoft products to something
else - revitalizing Mozilla/Netscape/Firefox and stimulating interest
in alternative platforms such as Linux and MacOS.

Precisely! As more and more computer users become fed up with having to
spend so much time trying to protect their systems from malware or fix
problems with malware that has slipped past their latest AV "protection",
the growing trend is to look towards more secure platforms, such as
GNU/Linux or Mac OSX. It is SO nice to be able to just work on ones
computer and not worry about the 100,000 plus viruses out there in the
wild ready to bring down ones system.

Sure - but be realistic as to *why* these choices are currently "more
secure"; it is because they are still minority targets.

That's just so much Microsoft FUD. Windoze is targeted because of its
inherent insecurity, not because of market share. Linux isn't targeted
because the damage a virus can cause on a Linux box is restricted to the
user's space who contracted the virus. No damage to the o/s itself.

Very significant exploitable defects have been found in the examples I
mentioned, but rarely is there a prompt (or pre-existing) exploit ITW.
Even when an ITW exploiter appears, spreading is slower because
there's just less of that target around.

A great target would be any server connected to the Internet - web server,
mail server, etc. The majority of the Internet is now driven on Linux/*NIX
servers. The targets are clearly there and the ports are open. Think about
why the Internet isn't being successfully attacked constantly.

So I expect you'd see the see-saw effect, i.e. as market share tilts
from MS to (say) Linux, so will the attention of malware writers and
those who employ them.

Nope.

OTOH, on a *NIX, you may have less drive-by vandalism etc. but you may
be up against human attackers with decades of *NIX experience. Sure,
it's great to have the power to edit the kernel, but do I want to pit
my skills against that lot, if I were acting as a sysadmin? In away,
I might rather have the alarm blown on each exploit opportunity by a
prompt rash of PoCs and bots ;-)


--------------- ----- ---- --- -- - - -
Never turn your back on an installer program
--------------- ----- ---- --- -- - - -

--
The ULTIMATE Windoze Fanboy:

http://video.google.com/videoplay?docid=-2370205018226686613

A 3D Linux Desktop (video) ...

http://www.youtube.com/watch?v=DUSn-jBA3CE

View Some Common Linux Desktops ...
http://shots.osdir.com/

.

Relevant Pages

  • Re: A Very Dangerous Worm in Windows Metafile Images (WMF)
    ... Post the whole URL, with warnings, so I can go look at it - ... > I wouldn't trust linux to protect you on on this one, ... I think one of the major problems with Windoze is that they ... In the first place, it doesn't have execute ...
    (sci.electronics.design)
  • Re: Will Linux become as vulnerable as MS ??
    ... > beeing vulnerable to viruses. ... > that they know are executable, and execute intentionally. ... >> Linux, each distro is a little different, and even within the distro, ... > Since clicking on a script is easier than typing it's name, ...
    (comp.os.linux.security)
  • Re: NASM source files extensions
    ... But we don't need an excuse to talk about Linux. ... If "a file" doesn't have the appropriate header, setting the executable bit will only change the error message from "permission denied" to "can't execute binary file". ... moment you tell the file system that it's an executable (by changing ... Is there a new standard shell, ...
    (alt.lang.asm)
  • Re: virusscanner
    ... The simple fact is that a virus written for Linux could not run under ... Unlike with Windows, you could not just click on a virus and allow it to ... execute because you cannot automatically save something with execute ...
    (alt.os.linux.suse)
  • Re: Suse 9.X and the SOBER worm
    ... "Sober" is a Microsoft Visual BASIC executable attachment that arrives ... execute binary program attachments received from nobody in particular. ... local Win32 registry (if this is an MS-Windows machine), ... sake of discussion that a Linux system emulates MS-Windows's structures ...
    (alt.os.linux.suse)