NCIS too. Gibbs (teh main character) can do no wrong. He storms into warehouses full of terrorists armed with AK-47s and greandes (they all miss), shoots a few shots from his pistol (it only takes 1 each) and walks away without a scratch. Not even his hair is messed up. He takes the most redicilous gambles and always wins. His hunches are always right, as proven by evidence later. He always hates the right people. He easily manipulates the evil (and stupid) terrorists without the reverse ever happening. Warrants be damned; he's above them. Illegal arrests and confinement? Illegal, taninted searches? Pah! He gets into pissing matches easily and always wins. Why doesn't he just put a bright spandex suit on?
I stopped watching this show after about 2 episodes, although not all my friends seem to hate it as much, so I still catch the occational scene; to remind me why I avoid it.
...the Registry was and is a big hole, but as a peer-poster says, "big dobs of stupid". Lots of compromise architecting to make WOW work, etc.
Eh? How is the registry a hole? Every key has an ACL. System hives are protected with the same file ACLs as the rest of the system files, and opened for exclusive access. User hives are protected with the rest of their profile. And WOW, it barely even uses the registry. It's mostly used to emulate.ini access for compatibility. Are you saying that WOW apps somehow are able to escilate their privileges? The registry is just a database with key-level security. The only difference between it and/etc on a UNIX is that/etc uses the filesystem's database instead of a specialized one.
VMS was (is) able to be secured to genuine high military levels with one configuration change. NT and children, with much work, can be certifiably secured only at the lowest levels and with ridiculous hardware configurations. The details in between are arguable, the results are not.
Which level are you referring to? NT3.5 SP3 and NT4.0 SP6a (full report) are both officially C2 certified (implied to have B1 support) by applying the C2 security templates. Unless something has made NT less secure in recent versions, this should still be true. Also, OpenVMS VAX Version 6.0, 6.1 and 6.1 Alpha are C2 certified. SEVMS VAX Version 6.0, 6.1 and 6.1 Alpha are certified B1, one level higher. OOO look! MS SQL Server 2000 v8 is certified C2 also. Hard to configure? All you have to do is apply the correct security template. Several are included, with varying degrees of security vs compatibility. See also this page.
Ridiculous hardware configurations! Like what? From the NT4 summary:
The hosting hardware for the Windows NT platform in the evaluated configuration includes single processor and multiprocessor versions of the Compaq Proliant Server models 6500 and 7000, and Compaq Professional Workstation models 5100 and 8000. It also includes a HP DAT SCSI tape drive and HP Laser Jet PCL5 printers. A networked configuration was evaluated for interconnecting the various hardware with Windows NT workstations and servers.
How is this ridiculous? All the certifications were done on a specific set of hardware. Hardware can introduce security problems for any operating system; this cert is very thorough by studying the entire computer.
The wonder technology was not Microsoft's; their contribution was to ship it, including embedded, with a *NULL* administrator password and to leave FoxPro to whither on the vine.
Good thing you don't have to keep the default. Even if this wasn't default, if you have an administrator so incompetent as to leave this as is, that person will find some other way to compromise the machine.
I never said that Microsoft didn't buy other companies for their technologies. We can only speculate on what those products would be like today if MS didn't buy them.
In each case, Microsoft took a good technology and tried to make it suck, with varying degrees of success.
<sarcasm>OH yeah. Microsoft intentionally ruined those products.</sarcasm>
NT4 has no hardware-accelerated Direct3d support. It was planned, but never happened. Service pack 3 was the last update to upgrade DirectX parts other than DirectPlay.What's the status of DirectX on Windows NT or Windows 2000?SP3 supports software emulated Direct3d only. No hardware support is only partial support. Also, the DirectSound implementaiton just used MCI with a notoriously oversized mixing buffer. Supported, but not that well. 2000 uses DirectSound directly and puts MCI on top of it.
No, it moved GDI into kernel mode. Win32 remains a mix between user-mode and kernel-mode; many Win32 APIs are just thin wrappers around the NT kernel API, others are more complex and have relatively significant user-mode portions.
It's true that client-side user-mode libraries do much of the work in all versions; acting as a thin wrapper for many win32 functions to the native API. I guess I should have been clearer: most of the server part of win32 moved from user mode to kernel mode. Since Windows's architecture is closed, it's hard to tell exactly how much moved. GDI, the window manager, messaging system, and video DirectX are definately in kernel mode now. Text console support, CSR hosted windows (such as the alt+tab window list, and the close due to not responding dialog) are still in user mode.
In NT3.51 (sp5), the Win32 server was implemented in winsrv.dll (1.3mb), csrsrv.dll (30k) and basesrv.dll (37k), hosted in csrss.exe. NT4 (sp0) still has those files, but they've become winsrv.dll (162k), csrsrv.dll (29k) and basesrv.dll (34k) and there is a new kernel-mode component: win32k.sys (1.2mb). This shows that the major bulk of binary code concerning the win32 server has moved into kernel mode. winsrv.dll shrunk by a factor of 8; that bulk showed up in win32k.sys. A total of 1367u/0k to 225u/1200k, or 4% growth total. For a comparison to client-side, the 4 main win32 client libs in 3.51 are kernel32.dll (329k), gdi32.dll (161k), user32.dll (210k), and advapi.dll (177k). In NT4, those same libs were still kernel32.dll (354k), gdi32.dll (186k), user32.dll (320k), and advapi.dll (240k). A total of 848k to 1140k, or 26% more. NT4 also added numerous features, which apparently expanded the client side more. Moving win32 simplified communication, so this growth was offset by needing less communication code. Microsoft may have also used a different version of their compiler which could throw things off significantly.
Someone created a list of all the functions that win32k.sys exports as services to user mode here. There are GDI, USER, DirectDraw, Direct3d, and DDE functions; 639 in all for Win2k. These are functions that used to be called using a LPC port in NT3.x to user mode csrss. And Microsoft actually documents some of the DirectDraw and Direct3d stuff here.
Windows NT: Large complex API with security boundary crossings scattered throughout, mediated by the callee.Not really. There is one system call interface (the Nt* functions in ntdll.dll only) of which all IPC must cross, all the IPC methods provide ACLs and impersonation (from the operating system), there is a single Object Manager that handles naming and security for all kernel objects, some sanity checks are done standard for all syscalls and there is a set of functions for other validity checks.
A user must have all rights required for any operation all the time.
No, there are alternative credentials, restricted SIDs and tokens, explicit-enable privileges, and jobs. These aren't used as often as they should be and more importantly, many apps are written poorly and don't play nicely with them.
Windows: Loose boundaries between applications and other components, libraries frequently have considerable state that can be shared between applications, even under different user IDs.
This is somewhat true (OLE/COM espescially), although many systems are client/server where the client libraries maintain a minimum of state information and the server coordinates. Most system services operate this way. UNIX has many client/server systems too and they usually either have the client store state explicitly or don't do it at all.
The tradeoff is that applications come to depend on low overhead high performance communications channels.
Like I said before, there are only 4 local communications channels: LPC, shared memory, IO Manager based which consist of [pipes, mailslots, files, and sockets], and Win32.USER for window messages. Win32 used to use LPC and shared memory exclusively, but became a special case when the server binary moved into kernel mode in NT4. You can send a message to any window that exists in a destop object that you have access to, and only to windows in your job if JOB_OBJECT_UILIMIT_HANDLES is set. Win32 isn't too great for security, so don't use it for secure communications; it's completely avoidable and sandboxable. There are absolutely no other ways to communicate. Apps cannot create under-the-table-magic communications pipes.
Under NTerprise, GDI calls were translated into X11 calls, with appropriate message bundling to provide decent performance.
Mmm, with a video driver that translates from Drv* to X calls? This is nothing special: it's the same way that RDP works. ...what does this have to do with security? The window manager's location is the most that could have changed. It still had to be compatible with win32.
I did have a nasty registry corruption thing in 95, but a transplant fixed that without reinstall.:) NT has registry and filesystem journalling that the 9xs don't, for one thing.
I've installed XPSP2 without any issues on my computer and 3 others.
Technically, in a really literal minded sense, that's correct. Technically, any Win32 component or control can be replaced. In practice, the way that Microsoft has built the system too much depends on the HTML control and Windows Explorer.
You're right. Too much depends on the shell and the shell isn't very secure.
For the latter, instead of mounting devices like my Jornada in the file system, they're shown on the desktop but are only there via a plugin for Windows Explorer, so without it I can't browse my Pocket PC.
That was the decision of the Jornada support programmers to create a shell extension instead of an actual filesystem driver. Still, I can see why: the offical filesystem SDK is about $1000 USD (it's mostly one header file and a free version can be had here). Also, writing an NT FSD isn't easy.
I can't have a great deal of faith in that design. There's just too much shared state between components of Windows, and too little control over the implementation of security boundaries: every component seems to have its own call gates, with multiple independent implementations of the same security and sanity checks on arguments and objects.
NT is object-oriented. At the heart of object management is the Object Manager. The Object Manager provides a namespace of named objects, manages handles to those objects, including opening and duplication. Kernel mode components can add their own types of objects to the object manager by implementing functions for manipulating them. The Object Manager is also the only component that handles security checks when a new handle is created (by opening or duplicating) unless the object type overrides the SecurityProcedure: the IO manager object type Device overrides it so it can ask the filesystem to provide an ACL instead of relying on the Object Manager to store every file's ACL. One system call is NtAccessCheck; this is the defined method to check an ACL against a token and a requested access mask. Microsoft is pretty good about using it or it's win32 equivalent AccessCheck. Note that this applies only to kernel objects, which comprise almost everything securable in the operating system. Desktop, window station and job objects are all kernel objects that fall under the Object Manager's domain. None of them supply a custom SeurityProcedure, so they are checked like any other object.
The NT kernel's design has all kinds of wonderful possibilities for building a secure OS around. I really wish Microsoft would do it.
So do I. Maybe Reactos?
The Win32 subsystem, however, is inherently insecure. And without the Win32 subsystem, NT is not a complete OS.
Yes, Win32 IS insecure, to a point. Window station, desktop and job objects are securable objects that NT adds that can be used to partition Win32 into sandboxes. They just aren't used much.
Win32, includes not just the GUI but the equivalent of all the UNIX daemons and system services, and large parts of what in UNIX would be kernel modules. Take that out and you're left with less than the UNIX kernel.
Most built in services are written for the Win32 subsystem since the user mode service control manager's interface is part of win32, but several have only superficial dependencies. The SMB client and server come to mind.
I thought that the NT had more, not less things running in kernel mode. Nothing in kernel mode depends on win32, ever. The only thing related to win32 that runs in kernel mode is win32k.sys, the server part of win32. Nothing in the kernel depends on win32, or can even use win32. Moving win32 into kernel mode didn't change that.
What, specifically, in Windows is implemented as a user-mode win32 dependent service that would normally be a kernel module in UNIX?
Also, there is no such thing as THE UNIX kernel. There are UNIX kernels such as Linux or OpenBSD's kernel, but no one 'true' UNIX kernel. Compared to Linux, the NT kernel and executive services (ntoskrnl.exe) do a couple of things that Linux doesn't: the Configuration Manager AKA the Registry; a database for configuration info, the extensible Object Manager (althought the VFS comes close), and a dedicated local proceduce call facility (you can use pipes under either, but only NT has LPC) If you include all the modules that run in kernel mode (besides win32), there is more: SMB: the client is in mrxsmb.sys and the server is in srv.sys, MUP (mup.sys), CD burning support (as a filesystem), audio processing, the mailslot filesystem (msfs.sys), the named pipe filesystem (npfs.sys), plus all the things you'd expect: filesystems, bus drivers, USB drivers, and network stuff.
If you were logged on to an NT workstation as a normal user, first of all, you're more likely to be infected by a virus in the first place because the design of the Win32 subsystem practically invites them in.
Invites? How's that?
Secondly, there's a lot more opportunities for an application to boost security to Administrator or even LOCALSYSTEM: not only is the security model very complex, but you have to have all the rights any application you run is ever going to need.
NT isn't any more vulnerable to privilege escilation than UNIX is. Just because the security model is complex, doesn't mean it is broken. It may be harder to use, but it also provides much granularity (if you use it). For the last part, I don't understand what you are trying to say; how is this different from any other security model? Define a user's permissions so that they can do everything they need to. ACLs can be changed, but you should be able to set them up once.
To top it all off, there's no hard "system call" interface between different security domains.
Sure there is. It's called the Native API. The only way to request services of the kernel is through the system call interrupt, and all those functions are exported by ntdll.dll. Win32k adds an extra function table, though; it exports the services that used to be in us
In particular, the horrendous remote security failures they brought over with Active Desktop make improvements in local security irrelevant.
An insecure shell environment does not make the entire operating system insecure. It isn't good, but it doesn't have to be fatal, either. Besides being replacable, it does not change the fact that normal users can't affect each other or the system.
Win32 is based on Win16, which does not have any security. Win32 does, however, have desktop, window station and job objects (like all objects, they each have an ACL) that are designed to be used to divide Win32 into seperate little pieces, each unable to talk to one another (using Win32 specific stuff). You can't get handles to win32 objects (like windows and the clipboard) unless you have access to the desktop and window station the window is in, and if your process is in a job you can't get to windows outside of your job if the JOB_OBJECT_UILIMIT_HANDLES flag set.
OTOH, the implementation and utilization of these features is somewhat lacking. Winlogon has a secure desktop (for ctrl+alt+delete) but Winlogon also creates insecure windows on the interactive desktop (against MS guidelines.) Window stations and desktops are rarely created, and then they usually get default security descriptors. The SAS desktop is about the only excpetion. Jobs are almost never even used. <shameless plug>I created jobprc for an easy way to put new processes into a job from the command-line. It can be used to contain processes in a win32 sandbox.
David Cutler, the main NT designer, and his staff were working on Mica, but Digital cancelled it and laid them off. Although Microsoft hired most of the VMS/Mica/Prism staff, no source code was actually copied. It's not suprising that the same team would create something very similar.
Oh yes. There are many ways that apps demand admin needlessly; this is one of the more extreme ways. I think you can get your tinfoil hats out for apps that do this: why else would they do something as silly as this, except to either make Windows hard(er) to use, or mabye that it will go away in a newer version? (and give you an artificial reason to upgrade)
My Windows' uptime 36 hours
My shortest of 6 Linux' uptime = 8 months 2 weeks and 3 days (had to change UPS battery, heh).
Last Windows reformat due to system file corruption: 3 months; average 1 time per year.
Last Linux reformat due to system file corruption: NEVER; average 0 times in 7 years.
Last Windows breach: 3 months ago, between install and d/l of SP4 (yeah, I couldn't even download the service pack before getting hit, I had to get the redistributable package via my Linux box and burn it to CD!)
Last Linux breach: NEVER
So you know how to run a Linux machine correctly, but are not competent to run a Windows machine? What result did you expect? I have never, ever reinstalled Windows, and I've had about 10 installtions. I've had zero viruses, worms or breaches. The uptime on this computer is 29 days, last restarted when I upgraded the video driver since nVidia can't afford to make an unloadable driver. In the year I've had this computer, I've had 3 crashes, all due to an expiremental IDE driver (for nForce2). Once I replaced it with the generic driver, it hasn't crashed since. (about 6 months ago)
Since I don't have the gross problems you report, I can only conclude that the user is at fault.
Last Windows breach: 3 months ago, between install and d/l of SP4 (yeah, I couldn't even download the service pack before getting hit, I had to get the redistributable package via my Linux box and burn it to CD!)
See Installing Windows 2000 integrated with the service pack (AKA slipstreaming). All the patches are applied to the installation files before actual installation. The command line arguments for the service pack exe to integrate them also apply to all recent patches.
Saying that UNIX and NT security are architecturally equivelent is insanity.
NT's security architecture is at least as secure as standard UNIX's. NT's defaults are not. Since they are just defaults, I can override them. If I were logged onto a NT workstation as a normal user and opened a virus the worst thing that can happen is my home directory will get deleted; the rest of the system cannot be affected. If I ran it as admin, it can do far worse. If I ran a UNIX virus as root, it's the same.
Secondly, I'm glad you're a savvy user, but the other 99% of the internet aren't so lucky. They're logged in as a computer administrator and could care less.
And that is the problem. User ignorance, stupidity, apathy and incompetence. I don't think that either Windows or UNIX are easy to make secure, or even possible if you don't know what you are doing. It is, however, possible to secure both and have a very usable machine. Defaults should never, ever be relied on to do what you want; they are a starting place only.
Windows 9x and NT are two seperate code bases. 95 is version 4.0 of the old dos-based Windows. 98 is 4.1 and ME is 4.2. Version 4.0 really did deserve a major revision with serious 32 bit support, a rewritten multimedia layer (DirectX), Plug+Play, power management, and an entirely new shell envrionment.
The first version of NT was numbered 3.1 so it would be aligned with the other Windows (I guess marketing thought it was a good idea). NT started with a completely fresh code base, so it should have been called 1.0. That would make NT4 version 2.0, Windows 2000 version 3.0, XP 3.1, and 2003 3.2. So, the NT line has only gone through two major revisions. NT4 added 95's shell environment, some DirectX and moved Win32 into kernel mode. I don't know if it deserved a major rev. alone, but compared to NT3.1, it does. Windows 2000 (NT5.0) uses Active Directory, a new version of NTFS, Plug+Play, all of DirectX, USB support, and many small improvements. It definately deserves a major revision.
The 'Available Memory' field in Task Manager does not mean 'Free Memory'. It is the amount free plus the standby list. See here. Basically, memory is agressively moved into the standby list. Memory on the standby list is in limbo: it is still in memory, but a copy is also written to the pagefile. That way, if it needs to go back, no disk access is needed because it is still in memory and if the memory is needed for something else, it can be discarded without disk access because a copy is already in the pagefile. It avoids disk access during light-moderate memory requests by doing it ahead of time. It avoids the condition of loading something into memory while trying to page something else out to make room; hard disks don't handle multiple simultaneous IO requests at the same time efficently because of all the seek overhead. The pagefile is still used to make copies of memory that hasn't been used recently, even when you have lots available because it would be a waste to keep unused pages of memory resident. It could be put to better use in a cache or made available in case it's needed later. This is true no matter how much memory you have. 'Available Memory' is the amount of memory that you can allocate without having to write anything new to the pagefile, mostly because a copy is already there.
The copy protection system "Safedisc" needs a kernel-mode driver to run on NT based OSes called secdrv.sys. Since installing kernel-mode drivers needs to be a privelege given only to trusted users, you need to run as admin so it can install the driver. Here is a good link from a WINE mailing list archive about it.
Sometimes apps want to write all their config stuff in HKLM, so they need access to that, or create temp files or config files in the Windows directory, along with blindly asking for write access to stuff in Program Files. Tools like Filemon and Regmon will show you those access attempts.
Any compiled language is susceptible to security holes. The problem is that the process of turning source code into binary code is opaque to the developer. He puts some code through the compiler and some binary object code pops out. Things like memory offsets, code areas, data areas, and all these esoteric issues that need to be dealt with are simply left to the compiler to decide.
Are you saying that all high-level languages that can compile use a process of producing machine language so opaque that the developers cannot produce predictable, consistent and detirminstic code without an extreme amount of effort?
Any self-respecting language will produce a binary that does what the source code says it should do, in exact detail. As for complexity or how much detail you get in that control, depends on the language. C and C++ are languages that give you some of the strongest control. Unfortunately, this amount of control can get you to hang yourself if you aren't careful. Use the best language for the problem. (they aren't all the same.)
Unlike interpreted languages which for the most part implement all code as either line-by-line interpretation or in bytecode form, compiled languages talk directly to the CPU. Interpreted environments have the additional benefit that they run inside of a sandbox that is abstracted from the hardware by some large degree. Because of this, the running code never actually touches the CPU directly.
Protected memory CPUs can provide every bit as much protection for the rest of the system as a VM can; it's hardware VM support for memory. That's the point of protected memory. Also, many VMs provide a on-demand compiler that produces native code so the program can execute directly on the CPU because it's faster. Any limits imposed on the language's environment can be done without a VM. Also, user-mode processes never talk to any hardware but the CPU and memory, as allocated by the OS.
The IBM AS/400 has no protected memory and does not need VMs to provide system security because there are only two ways to get binary code onto the system: 1. From a trusted source or 2. from a trusted compiler that only produces code that adheres to security regulations.
Things like the "no-execute" bit on modern CPUs provide an additional layer of security and prevent purposely damaged code from running directly on the CPU. However, until operating systems implement this in their own code, any application that does not want to adhere to the no-exec flag does not have to. This is like flock on Unix which only sets a file locking flag which applications are expected to obey rather than true file locking as implemented on other systems.
The no-execute bit provides hardware negation of a certain type of attack. It does not protect against corruption of program memory, which can lead to crashes and other types of vulns. Yes, like many things, it only works effectively when it's used correctly. The most common form of buffer overrun that can lead to code execution is on the stack. Unless the compiler (or the assembly) produces code that needs the stack to be executable, the operating system can safely mark all thread stacks as no-execute. Although you can move the stack to some private section of memory, the OS is usually aware of where the thread's stack is because it's needed to start the thread and it isn't normally moved. XPSP2 in Windows does this for all threads in system service processes by default when the NX bit is supported, or programs not on a blacklist upon request.
Your complete lack of any actual reasons for your conclusions leaves nothing to discuss. You've made your position quite obvious, but you haven't provided any support for it at all. You need to tell me specificallyhow and why you think Windows is bad. You can start by answering the questions I asked (and you ignored) in my previous post. It's nice that you pity them, but that sentiment is awefully shallow by itself, without details.
Eh? Are you saying that Windows NT and its ilk are underpowered; that they will cause a big bottleneck in running Apache?
why on earth would you use a 'consumer' OS
Because NT isn't a consumer OS?
pay license fees thru the wazoo to run it on, instead of linux, freebsd, or some other unix.
No licence fees if you already have it. Not all unixes are free, either.
What if you needed to run other apps that are Windows-only on the same machine, rather than get another computer or deal with a VM? What if the server admin knows Windows and doesn't know unix? Wouldn't you rather the admin work on an OS that they know? Not everyone likes and wants to run unix. PHBs/idiots/forced people aren't the only Windows users. A Windows server can be every bit as stable, secure, fast and usable as a *nix machine, if the admins knows what they are doing. This all applies in reverse, too.
If you are worried about that, besides disabling LM hashes, you can encrypt the entire SAM database with a password or random key on a floppy disk with syskey on NT4 and later. The key will be required at startup before you can logon.
Ok. The page I liked to was about protocols, not hashes. I didn't know there was a LMv2, but apparently there is. Do 9x machines with the Active Directory client pack use LMv2? Microsoft says they use NTLMv2, but some things like case-insensitive passwords make me wonder. Er, from your page it says
Under NTLMv2, however, the older NTLM (v1) Hash is used instead of the password to generate the new hash. A server or Domain Controller being upgraded to use NTLMv2 may already have the older NTLM hash values in its authentication database.
which implies that there are two types of NTLM hashes: v1 and v2. The v2 hash is the v1 hash plus the user name and "logon destination" (domain?), rehashed.
Anyways, your book is VERY informative; a veritable reference manual. I've bookmarked it.
Rabbit-pellet mode!:) I've seen that; nice to have a name for it.
Seriously, all my Windows machines are stable and if Apache is the only thing with reachable ports, how is the machine not secure? If there aren't any good reasons to run Apache on Windows then why is there an official distrobution for it?
In the local Security Policy->Security Options, you want to change "Network security: Lan Manager authentication level" to at least "Send NTLM response only". Or the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\LmCompatibilityLevel to at least 2.
See this page for this and related policies. This for an overview of LM, NTLM and NTLMv2. And here to see how to prevent storage of LM hashes.
Er, this page says that there is only one type of LM hash and two versions of NTLM. LM is supported for DOS, the original Lan Manager, and 9x. NTLM_V1 is supported on all versions of NT and NTLM_V2 is on NT4 SP3 and 9x with the Active Directory client update.
To stop this compatibility behavior, see the MS knowledge base article Q299656.
Basically, you want the security policy "Network security: Do not store LAN Manager hash value on next password change." in Group Policy->Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options. Or you can set the registry value the policy sets directly: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\NoLMHash. Note that on 2000 and earlier, this prevents only the creation of new LM hashes; it does not delete old ones. The registry key on XP and 2003 clears all LM hashes.
This will also break connections to 9x machines unless they have the Active Directory Client update installed.
First problem: what is a breach? If someone takes down a hosting company's Linux server that is hosting 5000 domains, and someone else takes down a Windows box with one domain and an OS X box with one domain, is that counted as 5000 Linux breaches, 1 Windows breach, and 1 OS X breach, or is it 1 breach of each OS?
You are implying that Linux servers host more domains/computer than Windows or OS X boxes do. Apache is the main web server type for Linux and it also runs on Windows and OS X. Are you saying there a technical reason that Linux hosts a higher ratio, or is it a social reason?
As for how breaches should be counted: I think that the more information available, the better. Show the amount of sites breached and the number of physical computers. A system that hosts multiple sites is a bigger problem if breached because it represents more damage. Some kind of weight system that gives extra points based on how big the computer is would be good. Make the data available (in a spreadsheet or something) so you can change the weight and do your own analysis if you want.
Slashdot Mirror
NCIS too. Gibbs (teh main character) can do no wrong. He storms into warehouses full of terrorists armed with AK-47s and greandes (they all miss), shoots a few shots from his pistol (it only takes 1 each) and walks away without a scratch. Not even his hair is messed up. He takes the most redicilous gambles and always wins. His hunches are always right, as proven by evidence later. He always hates the right people. He easily manipulates the evil (and stupid) terrorists without the reverse ever happening.
Warrants be damned; he's above them.
Illegal arrests and confinement? Illegal, taninted searches? Pah!
He gets into pissing matches easily and always wins.
Why doesn't he just put a bright spandex suit on?
I stopped watching this show after about 2 episodes, although not all my friends seem to hate it as much, so I still catch the occational scene; to remind me why I avoid it.
The registry is just a database with key-level security. The only difference between it and
Hard to configure? All you have to do is apply the correct security template. Several are included, with varying degrees of security vs compatibility. See also this page.
Ridiculous hardware configurations! Like what? From the NT4 summary:How is this ridiculous? All the certifications were done on a specific set of hardware. Hardware can introduce security problems for any operating system; this cert is very thorough by studying the entire computer.Good thing you don't have to keep the default. Even if this wasn't default, if you have an administrator so incompetent as to leave this as is, that person will find some other way to compromise the machine.
I never said that Microsoft didn't buy other companies for their technologies. We can only speculate on what those products would be like today if MS didn't buy them.<sarcasm>OH yeah. Microsoft intentionally ruined those products.</sarcasm>
Also, the DirectSound implementaiton just used MCI with a notoriously oversized mixing buffer. Supported, but not that well. 2000 uses DirectSound directly and puts MCI on top of it.It's true that client-side user-mode libraries do much of the work in all versions; acting as a thin wrapper for many win32 functions to the native API. I guess I should have been clearer: most of the server part of win32 moved from user mode to kernel mode. Since Windows's architecture is closed, it's hard to tell exactly how much moved. GDI, the window manager, messaging system, and video DirectX are definately in kernel mode now. Text console support, CSR hosted windows (such as the alt+tab window list, and the close due to not responding dialog) are still in user mode. In NT3.51 (sp5), the Win32 server was implemented in winsrv.dll (1.3mb), csrsrv.dll (30k) and basesrv.dll (37k), hosted in csrss.exe. NT4 (sp0) still has those files, but they've become winsrv.dll (162k), csrsrv.dll (29k) and basesrv.dll (34k) and there is a new kernel-mode component: win32k.sys (1.2mb). This shows that the major bulk of binary code concerning the win32 server has moved into kernel mode. winsrv.dll shrunk by a factor of 8; that bulk showed up in win32k.sys. A total of 1367u/0k to 225u/1200k, or 4% growth total.
For a comparison to client-side, the 4 main win32 client libs in 3.51 are kernel32.dll (329k), gdi32.dll (161k), user32.dll (210k), and advapi.dll (177k). In NT4, those same libs were still kernel32.dll (354k), gdi32.dll (186k), user32.dll (320k), and advapi.dll (240k). A total of 848k to 1140k, or 26% more.
NT4 also added numerous features, which apparently expanded the client side more. Moving win32 simplified communication, so this growth was offset by needing less communication code. Microsoft may have also used a different version of their compiler which could throw things off significantly.
Someone created a list of all the functions that win32k.sys exports as services to user mode here. There are GDI, USER, DirectDraw, Direct3d, and DDE functions; 639 in all for Win2k. These are functions that used to be called using a LPC port in NT3.x to user mode csrss. And Microsoft actually documents some of the DirectDraw and Direct3d stuff here.
I did have a nasty registry corruption thing in 95, but a transplant fixed that without reinstall. :)
NT has registry and filesystem journalling that the 9xs don't, for one thing.
I've installed XPSP2 without any issues on my computer and 3 others.
The Object Manager is also the only component that handles security checks when a new handle is created (by opening or duplicating) unless the object type overrides the SecurityProcedure: the IO manager object type Device overrides it so it can ask the filesystem to provide an ACL instead of relying on the Object Manager to store every file's ACL.
One system call is NtAccessCheck; this is the defined method to check an ACL against a token and a requested access mask. Microsoft is pretty good about using it or it's win32 equivalent AccessCheck.
Note that this applies only to kernel objects, which comprise almost everything securable in the operating system.
Desktop, window station and job objects are all kernel objects that fall under the Object Manager's domain. None of them supply a custom SeurityProcedure, so they are checked like any other object.
So do I. Maybe Reactos?
Yes, Win32 IS insecure, to a point. Window station, desktop and job objects are securable objects that NT adds that can be used to partition Win32 into sandboxes. They just aren't used much.
Most built in services are written for the Win32 subsystem since the user mode service control manager's interface is part of win32, but several have only superficial dependencies. The SMB client and server come to mind.
I thought that the NT had more, not less things running in kernel mode. Nothing in kernel mode depends on win32, ever. The only thing related to win32 that runs in kernel mode is win32k.sys, the server part of win32. Nothing in the kernel depends on win32, or can even use win32. Moving win32 into kernel mode didn't change that.
What, specifically, in Windows is implemented as a user-mode win32 dependent service that would normally be a kernel module in UNIX?
Also, there is no such thing as THE UNIX kernel. There are UNIX kernels such as Linux or OpenBSD's kernel, but no one 'true' UNIX kernel.
Compared to Linux, the NT kernel and executive services (ntoskrnl.exe) do a couple of things that Linux doesn't: the Configuration Manager AKA the Registry; a database for configuration info, the extensible Object Manager (althought the VFS comes close), and a dedicated local proceduce call facility (you can use pipes under either, but only NT has LPC) If you include all the modules that run in kernel mode (besides win32), there is more: SMB: the client is in mrxsmb.sys and the server is in srv.sys, MUP (mup.sys), CD burning support (as a filesystem), audio processing, the mailslot filesystem (msfs.sys), the named pipe filesystem (npfs.sys), plus all the things you'd expect: filesystems, bus drivers, USB drivers, and network stuff.
Invites? How's that?
NT isn't any more vulnerable to privilege escilation than UNIX is. Just because the security model is complex, doesn't mean it is broken. It may be harder to use, but it also provides much granularity (if you use it). For the last part, I don't understand what you are trying to say; how is this different from any other security model? Define a user's permissions so that they can do everything they need to. ACLs can be changed, but you should be able to set them up once.
Sure there is. It's called the Native API. The only way to request services of the kernel is through the system call interrupt, and all those functions are exported by ntdll.dll. Win32k adds an extra function table, though; it exports the services that used to be in us
Win32 is based on Win16, which does not have any security. Win32 does, however, have desktop, window station and job objects (like all objects, they each have an ACL) that are designed to be used to divide Win32 into seperate little pieces, each unable to talk to one another (using Win32 specific stuff).
You can't get handles to win32 objects (like windows and the clipboard) unless you have access to the desktop and window station the window is in, and if your process is in a job you can't get to windows outside of your job if the JOB_OBJECT_UILIMIT_HANDLES flag set.
OTOH, the implementation and utilization of these features is somewhat lacking. Winlogon has a secure desktop (for ctrl+alt+delete) but Winlogon also creates insecure windows on the interactive desktop (against MS guidelines.) Window stations and desktops are rarely created, and then they usually get default security descriptors. The SAS desktop is about the only excpetion. Jobs are almost never even used.
<shameless plug>I created jobprc for an easy way to put new processes into a job from the command-line. It can be used to contain processes in a win32 sandbox.
How has the architecture changed to make it insecure? Not the implementation, but the design. Be specific.
I think it has gotten MORE secure in design than it was: Active Directory with Kerberos, job objects that enforce quotas, deny-only SIDs, restricted tokens and SIDs, deleted privledges, SAM encryption, NTLMv2, group policies, a replacable GINA, Windows authentication packages (aka SSP)...
David Cutler, the main NT designer, and his staff were working on Mica, but Digital cancelled it and laid them off. Although Microsoft hired most of the VMS/Mica/Prism staff, no source code was actually copied. It's not suprising that the same team would create something very similar.
Oh yes. There are many ways that apps demand admin needlessly; this is one of the more extreme ways.
I think you can get your tinfoil hats out for apps that do this: why else would they do something as silly as this, except to either make Windows hard(er) to use, or mabye that it will go away in a newer version? (and give you an artificial reason to upgrade)
I have never, ever reinstalled Windows, and I've had about 10 installtions.
I've had zero viruses, worms or breaches.
The uptime on this computer is 29 days, last restarted when I upgraded the video driver since nVidia can't afford to make an unloadable driver.
In the year I've had this computer, I've had 3 crashes, all due to an expiremental IDE driver (for nForce2). Once I replaced it with the generic driver, it hasn't crashed since. (about 6 months ago)
Since I don't have the gross problems you report, I can only conclude that the user is at fault.See Installing Windows 2000 integrated with the service pack (AKA slipstreaming). All the patches are applied to the installation files before actual installation. The command line arguments for the service pack exe to integrate them also apply to all recent patches.
Windows 9x and NT are two seperate code bases. 95 is version 4.0 of the old dos-based Windows. 98 is 4.1 and ME is 4.2. Version 4.0 really did deserve a major revision with serious 32 bit support, a rewritten multimedia layer (DirectX), Plug+Play, power management, and an entirely new shell envrionment.
The first version of NT was numbered 3.1 so it would be aligned with the other Windows (I guess marketing thought it was a good idea). NT started with a completely fresh code base, so it should have been called 1.0. That would make NT4 version 2.0, Windows 2000 version 3.0, XP 3.1, and 2003 3.2. So, the NT line has only gone through two major revisions. NT4 added 95's shell environment, some DirectX and moved Win32 into kernel mode. I don't know if it deserved a major rev. alone, but compared to NT3.1, it does. Windows 2000 (NT5.0) uses Active Directory, a new version of NTFS, Plug+Play, all of DirectX, USB support, and many small improvements. It definately deserves a major revision.
The 'Available Memory' field in Task Manager does not mean 'Free Memory'. It is the amount free plus the standby list. See here. Basically, memory is agressively moved into the standby list. Memory on the standby list is in limbo: it is still in memory, but a copy is also written to the pagefile. That way, if it needs to go back, no disk access is needed because it is still in memory and if the memory is needed for something else, it can be discarded without disk access because a copy is already in the pagefile. It avoids disk access during light-moderate memory requests by doing it ahead of time. It avoids the condition of loading something into memory while trying to page something else out to make room; hard disks don't handle multiple simultaneous IO requests at the same time efficently because of all the seek overhead.
The pagefile is still used to make copies of memory that hasn't been used recently, even when you have lots available because it would be a waste to keep unused pages of memory resident. It could be put to better use in a cache or made available in case it's needed later. This is true no matter how much memory you have.
'Available Memory' is the amount of memory that you can allocate without having to write anything new to the pagefile, mostly because a copy is already there.
The copy protection system "Safedisc" needs a kernel-mode driver to run on NT based OSes called secdrv.sys. Since installing kernel-mode drivers needs to be a privelege given only to trusted users, you need to run as admin so it can install the driver.
Here is a good link from a WINE mailing list archive about it.
Sometimes apps want to write all their config stuff in HKLM, so they need access to that, or create temp files or config files in the Windows directory, along with blindly asking for write access to stuff in Program Files. Tools like Filemon and Regmon will show you those access attempts.
Any self-respecting language will produce a binary that does what the source code says it should do, in exact detail. As for complexity or how much detail you get in that control, depends on the language. C and C++ are languages that give you some of the strongest control. Unfortunately, this amount of control can get you to hang yourself if you aren't careful. Use the best language for the problem. (they aren't all the same.)Protected memory CPUs can provide every bit as much protection for the rest of the system as a VM can; it's hardware VM support for memory. That's the point of protected memory. Also, many VMs provide a on-demand compiler that produces native code so the program can execute directly on the CPU because it's faster. Any limits imposed on the language's environment can be done without a VM.
Also, user-mode processes never talk to any hardware but the CPU and memory, as allocated by the OS.
The IBM AS/400 has no protected memory and does not need VMs to provide system security because there are only two ways to get binary code onto the system: 1. From a trusted source or 2. from a trusted compiler that only produces code that adheres to security regulations.The no-execute bit provides hardware negation of a certain type of attack. It does not protect against corruption of program memory, which can lead to crashes and other types of vulns. Yes, like many things, it only works effectively when it's used correctly. The most common form of buffer overrun that can lead to code execution is on the stack. Unless the compiler (or the assembly) produces code that needs the stack to be executable, the operating system can safely mark all thread stacks as no-execute. Although you can move the stack to some private section of memory, the OS is usually aware of where the thread's stack is because it's needed to start the thread and it isn't normally moved. XPSP2 in Windows does this for all threads in system service processes by default when the NX bit is supported, or programs not on a blacklist upon request.
Your complete lack of any actual reasons for your conclusions leaves nothing to discuss. You've made your position quite obvious, but you haven't provided any support for it at all.
You need to tell me specifically how and why you think Windows is bad. You can start by answering the questions I asked (and you ignored) in my previous post.
It's nice that you pity them, but that sentiment is awefully shallow by itself, without details.
What if you needed to run other apps that are Windows-only on the same machine, rather than get another computer or deal with a VM?
What if the server admin knows Windows and doesn't know unix? Wouldn't you rather the admin work on an OS that they know?
Not everyone likes and wants to run unix. PHBs/idiots/forced people aren't the only Windows users.
A Windows server can be every bit as stable, secure, fast and usable as a *nix machine, if the admins knows what they are doing.
This all applies in reverse, too.
If you are worried about that, besides disabling LM hashes, you can encrypt the entire SAM database with a password or random key on a floppy disk with syskey on NT4 and later. The key will be required at startup before you can logon.
Er, from your page it sayswhich implies that there are two types of NTLM hashes: v1 and v2. The v2 hash is the v1 hash plus the user name and "logon destination" (domain?), rehashed.
Anyways, your book is VERY informative; a veritable reference manual. I've bookmarked it.
Rabbit-pellet mode!
I've seen that; nice to have a name for it.
Apache on Windows:
Stable- Check.
Secure- Check.
Seriously, all my Windows machines are stable and if Apache is the only thing with reachable ports, how is the machine not secure? If there aren't any good reasons to run Apache on Windows then why is there an official distrobution for it?
LM != NTLM. The article is about LM which is used for network compatibility with DOS, Lan Manager, and Win9x. NT has always supported NTLM.
In the local Security Policy->Security Options, you want to change "Network security: Lan Manager authentication level" to at least "Send NTLM response only". Or the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa\LmCompatibilityLevel to at least 2.
See this page for this and related policies.
This for an overview of LM, NTLM and NTLMv2.
And here to see how to prevent storage of LM hashes.
Er, this page says that there is only one type of LM hash and two versions of NTLM. LM is supported for DOS, the original Lan Manager, and 9x. NTLM_V1 is supported on all versions of NT and NTLM_V2 is on NT4 SP3 and 9x with the Active Directory client update.
To stop this compatibility behavior, see the MS knowledge base article Q299656.
o l\Lsa\NoLMHash.
Basically, you want the security policy "Network security: Do not store LAN Manager hash value on next password change." in Group Policy->Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options.
Or you can set the registry value the policy sets directly: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr
Note that on 2000 and earlier, this prevents only the creation of new LM hashes; it does not delete old ones. The registry key on XP and 2003 clears all LM hashes.
This will also break connections to 9x machines unless they have the Active Directory Client update installed.
As for how breaches should be counted: I think that the more information available, the better. Show the amount of sites breached and the number of physical computers. A system that hosts multiple sites is a bigger problem if breached because it represents more damage. Some kind of weight system that gives extra points based on how big the computer is would be good. Make the data available (in a spreadsheet or something) so you can change the weight and do your own analysis if you want.