Re: MS and security: good effort but no cigar
From: Dan (spamyou_at_user.nec)
Date: 02/23/05
- Next message: Dan: "Re: Changes in Windows XP Product Activation"
- Previous message: Clayton: "Re: A:\ Drive Incorrect Function"
- In reply to: mar: "MS and security: good effort but no cigar"
- Next in thread: SlowJet: "Re: MS and security: good effort but no cigar"
- Reply: SlowJet: "Re: MS and security: good effort but no cigar"
- Reply: Steve N.: "Re: MS and security: good effort but no cigar"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 23 Feb 2005 12:02:54 -0700
The core of XP PRO is based upon a command.com (cmd.com) prompt within a DOS
(Disk Operating System) emulator that is encassed within a DOS shell.
Microsoft saved money by making NT (New Technology) without a new maintenance
operating system. The NT (Not There) according to Microsoft's own techs.
according to a history book on Microsoft said that it was "crazy" to do it
this way but they had orders and were not about to break them. As you can
see a true hacker can attack the false MS-DOS core because it is insecure.
At least 98SE based upon 9x source code has a true solid core that is based
upon real DOS but with less capabilities. Some commands were removed instead
of Microsoft updating them Microsoft saved money by just removing them.
Parts of the NT (New Technology) source code have already been leaked out
over the internet. This is not the case with 9x source code. It has not
been leaked and the core is more stable than NT (XPPRO, XPHOME, 2000, etc.)
Also, 98SE is easier to understand. Sure it does not have as many services
but that means less points of entry for hackers to attack. I do not
understand why people will not accept this. Microsoft XP PRO. is not secure.
Its foundation is built upon sand and not rock. Microsoft needs to build a
brand new maintenance operating system and stear clear of DOS with Longhorn
or successors. DOS and 9x must either continue as a Classics line that
Microsoft could continue to get revenue from or be sold or given to the
open-source community for the good of all mankind. Have a nice day and I
look forward to hearing from you.
"mar" <anonymous@discussions.microsoft.com> wrote in message
news:383siaF5h4h65U1@individual.net...
: MS and security: good effort but no cigar
: By Mark Burnett, SecurityFocus
: Published Wednesday 23rd February 2005 10:42 GMT
: http://www.theregister.co.uk/2005/02/23/ms_security_issues/
:
: Last week I watched the webcast of Bill Gates speaking at the RSA
: conference in San Francisco. He talked about Microsoft's plans to
: build upon the progress it's already made in security. These plans
: included better protection against spyware and spam. Gates also
: announced Microsoft's intention to release Internet Explorer 7,
: complete with a number of security improvements, by the end of this
: year.
:
: Looking back, the company has indeed made notable progress in the
: security of its software. Windows XP SP2 is a significant achievement,
: and Gates reported that over 170 million people have downloaded the
: update. The low-hanging fruit of millions of insecure Windows machines
: is rapidly falling from the tree.
:
:
: But we're not out of the woods yet. If you can gain any user access to
: a Windows system, it is still surprisingly easy to completely own that
: box. So far, these problems have been overshadowed by the countless
: remote holes we've seen in recent years, but privilege escalation by
: authorized users is an important issue today that is still too easy to
: exploit.
:
: Take, for example, the way that Windows handles file paths with
: spaces. Suppose that you want to run the following command:
:
: C:\Program Files\Internet Explorer\iexplore
:
: One cool thing about Windows is that although the path contains a
: space, it still runs the application fine, even if you don't place
: quotes around the entire command and even if you don't use the
: executable extension for iexplore.exe.
:
: But how does Windows know where the program path ends and the
: program's command line parameters begin? How does it know that the
: user isn't trying to run a program named "C:\Program.exe" with the
: parameter "Files\Internet Explorer\iexplore?"
:
: The problem is that it doesn't know. It just starts at the beginning
: and tries finding an executable until it finds a match. So in this
: case, it will try these files every time you run the command:
:
: C:\Program.exe
: C:\Program Files\Internet.exe
: C:\Program Files\Internet Explorer\iexplore.exe
:
: You might see where I'm going with this: if you place an executable
: named program.exe in the root directory, it will probably end up
: running quite a bit. In fact, it will run anytime Windows launches a
: Program Files executable that does not have quotes around the path.
:
: Microsoft certainly is aware of this issue. In fact, it was probably a
: design decision at some point. If you run Windows XP, try placing an
: executable named program.exe and reboot your system. When it restarts,
: Windows will warn you about the complications of having that file
: there.
:
: Here's the problem: there are thousands of paths in the registry that
: do not have quotes around them, and many Windows systems have weak
: NTFS permissions that allow any user to write to the root directory.
: This is bad. As an experiment, I created a small program that simply
: logged every time it ran and under what user context. I rebooted and
: checked my Event Log. It turned out that on my system it ran eight
: times, twice under the context of the SYSTEM account and the rest as
: my own administrative account.
:
: Of course, I got the message box warning of the file, so I made a
: slight modification to my program.exe. It turns out there is a
: registry key that you can set to turn off this warning. I simply
: change that setting every time my program runs. Since the first couple
: instances executed before I even logged in, there was no warning at
: all. And of course, there are plenty other executable name variations
: that Windows does not check.
: Criminals get smarter
:
: This could be a serious issue, and it's not the only one. Another
: weakness is all the batch files and scripts that administrators use.
: Sure, scripts are convenient, but you must take care to protect these
: files. Too many administrators leaving them laying around in
: directories where Everyone has write access to the files. All an
: attacker with low-privileged access needs to do is add their code of
: choice to the end of your script and it runs under your security
: context the next time you use the script.
:
: Fortunately, Windows allows you to enforce script signing policies,
: but there is no way to enforce signing of a batch file. You must also
: protect files such as .reg, and .inf that an attacker might exploit.
: If you use scripts on your servers, make sure they have strong NTFS
: permissions.
:
: Then there's the issue of poorly secured server applications. In my
: experience, third party Windows mail servers are particularly
: vulnerable. Some let you run code based on an email message, use
: executable auto-responders, and execute external virus and filtering
: applications. But what happens if the user is able to run any
: application of choice?
:
: I have seen many, many mail server directories that allow all users
: full control over the files in that directory. Sometimes it's the mail
: server installer that does this and sometimes it is the
: administrator's fault. Some mail servers even require loose
: permissions for some user features to work properly.
:
: This means that regular users can modify these settings and send
: themselves an email to get executables running in the context of the
: mail server's service - which is often the SYSTEM account. Obviously,
: I'm oversimplifying what's involved here, but take a close look at the
: file permissions for your server applications. Can users get the
: server to run their code?
:
: Depending on your server, you should even consider denying all access
: to any account besides the service account. Too many server
: applications store user passwords using weak encryption and all an
: attacker might need is Read access to that file. Many of these flaws
: are well known, and there are many more that are still not publicly
: known. Most users do not need Read access to these files.
:
: So far, I have only scratched the surface. There are problems with FTP
: client apps storing passwords, browser issues, auto run issues, and of
: course, the serious problems of physical server access. We have raised
: the bar some, but we are nowhere near done. If you have any access to
: a system, you can likely gain administrative access.
:
: Sure, Microsoft is eliminating the low-hanging fruit. But what happens
: when there is no more low-hanging fruit? Crime doesn't stop because it
: is harder. Criminals get smarter. The question is, will we be ready
: when that time comes?
:
: Copyright © 2004,
:
: Mark Burnett is an independent researcher, consultant, and writer
: specializing in Windows security. He is the author of Hacking the
: Code: ASP.NET Web Application Security (Syngress), co-author of the
: best-selling book Stealing The Network: How to Own the Box (Syngress),
: and co-author of Maximum Windows 2000 Security (SAMS Publishing). He
: is a contributor and technical editor for Special Ops: Host and
: Network Security for Microsoft, UNIX, and Oracle. Mark speaks at
: various security conferences and has published articles in Windows IT
: Pro Magazine (formerly Windows & .NET Magazine), Redmond Magazine,
: Information Security, Windows Web Solutions, Security Administrator
: and various other print and online publications. Mark is a Microsoft
: Windows Server Most Valued Professional for Internet Information
: Services.
- Next message: Dan: "Re: Changes in Windows XP Product Activation"
- Previous message: Clayton: "Re: A:\ Drive Incorrect Function"
- In reply to: mar: "MS and security: good effort but no cigar"
- Next in thread: SlowJet: "Re: MS and security: good effort but no cigar"
- Reply: SlowJet: "Re: MS and security: good effort but no cigar"
- Reply: Steve N.: "Re: MS and security: good effort but no cigar"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
