M$ actually getting security?

I'm not talking about their top brass, who are still as clueless as ever (witness Gates's speech on firewalls or every time Balmer opens his dumb yap on the subject)..

but, someone in there is understanding security a bit more.

the NX bit for the Opteron is interesting... it impliments the same general kind of protections in hardware that the PaX guys, OpenBSD, and Red Hat (Execshield) people have in their software solutions.

PaX and probably the OpenBSD solution are still superior, but the fact that M$ is even messing with this stuff is very interesting IMO.

I think one thing they have yet to probably get is truly priviledge seperated programs a la OpenBSD.. plus it's such a pain in the fucking ass to try and run stuff as non-Adminstrator in Windows, because everything requires Adminstrator rights.

first M$ needs to get most stuff running as non-root/Admin, then they need to start priviledge seperating their programs that need to run as Admin or System into pieces where a small codebase runs as Admin and everything else runs as User....

then again, this takes serious time and effort to do right.

of course, they need to fucking give up on ActiveX in browsers, etc.

that stuff is still fucking evil.

and they need to abandon all production of Outlook

well, they're beefing up Outlook with some security enhancements and features....

which probably won't do shit in the long run, as Outlook is a lost cause IMO.

also, one disturbing thing...

Microsoft's automatic stack protection shipped in it's Visual Studio program is totally broken from a security standpoint, according to Marc Litchfield, who is a Windows vunerability pimp.

it was clean room based on Immunix's GPL'ed Stackguard... which isn't perfect, but works a whole hell of a lot better than the /GS option.

Stackguard can in some cases be gotten around, but it takes some serious assembler-fu. By layering on other protections, it can be made a lot harder.

apparently, /GS is totally easy to get around... and Microsoft hasn't fixed it.

plus, lots of things that were supposedly compiled with /GS to give it protection, apparently WEREN'T compiled with it...

I'm suprised they just didn't grab Propolice/SSP and use it... it's BSD-licensed now because the BSD's wanted to use it, so IBM licensed it under that.

hmm, nevermind... it must not be BSD licensed... it
integrates tightly with GCC so I think it's GNU

but if they clean roomed Stackguard, why not clean
room Propolice? It's a better and broader design.

of course, they need to fucking give up on ActiveX in browsers, etc.Actually, I disagree. I write binary DHTML behaviors for client apps that use the IE DOM and you just can't make a better looking GUI with Win32 controls. I'm all for disabling the feature by default, but getting rid of COM components running in IE is rediculous.

I'm just looking at it from a security standpoint.

from a security standpoint, I would scrub ActiveX at the firewall ALL DAY LONG.

ActiveX's so called security system blows goats. digital signing does precisely jack, and the half-hearted attempts to graft on a Java-style security model are basically worthless.

Java has it's problems, and it's not unbreakable, but it's security architecture is far superior for mobile code.

(edited- misunderstood you.)

What do you mean scrub it from the firewall? ActiveX components run locally and they are downloaded in the form of CAB files if you accept them. Otherwise, you are thinking of DCOM over HTTP, which nobody allows through. That's why SOAP/XML is so popular. So I guess I don't get your point. What are you thinking is the security issue exactly?

I mean scrubbing ActiveX containing mobile code transmitted over the pipe to your network, which you can do with string matching in some firewalls (pf, probably IPTables, I know jack about the major commerical firewalls so I can't comment there but I would assume you could do it there as well.)

you load a ruleset that would block any transfer of files with ActiveX . extensions, except for a whitelist of exceptions for any required files, from getting past the firewall to the Windows machines.

mainly so users can't download ActiveX files and screw things up.

I'd have to ask an experienced network admin to be 100% confident in this, but I'm not sure what the options are at a firewall. Basically, an ActiveX component is placed in an object tag. If the browser tries to load the component associated with the GUID in that tag and it can't find it in the registry, there's usually a link to a CAB file for installation. Now, an admin could set browser rules to not allow ActiveX downloads. Outside of that, I think the CAB will always get installed if the user is prompted and they click "Yes" to install. Once that puppy is installed, it works like any other piece of software.

So, that being said, I'm not sure you can do anything besides blocking HTML object tags. That screws up other things like flash components. Maybe firewall software recognizes GUIDs? I've never heard of that. I think many admins make these settings at the browser level. I'd be interested for someone with experience in that matter chiming in on this. I'm really curious now because I'm not a network admin, I'm a developer, and like I said before, I've written a ton of Binary DHTML behaviors which get loaded the same way an ActiveX control does in the browser. It's a COM DLL.

first M$ needs to get most stuff running as non-root/AdminJust as a side-note Rob, I totally agree with you on this. The problem is not just Microsoft, it's ALL developers. Ask most developers and they are logged in as admins when they are writing their software. It's a bad practice. Everyone should be logged in as a regular user (with those permissions) and write their code. It's a whole new world with many challenges, but you can get used to it and your code will be more secure and friendly to the real world. For example, if your software is touching directories that normal users don't have access to, it will puke in production when you release it.But.....as far as you saying "they need to fucking give up on ActiveX in browsers, etc", that's throwing the baby out with the bath water. As software developers, that takes away the abilities we need to write software such as binary DHTML behaviors. A better solution is to lock down that ability to certain trusted zones or something, NOT completely eliminating the ability.

I think you can be selective on the firewall if you have installed string matching goop - you could block particular object tags... I think.

I KNOW for certain you could do it if you have a proxy firewall set up for HTTP...
I'm gonna install OBSD on my old machine, fire up PF, and throw some packets at it next weekend..... I'll see if I can block ActiveX stuff from getting through.

Yup - I think you can actually. I haven't found out for sure, but it seems reasonable. That would be good, then just software companies can roll out stuff like binary behaviors. Catch it at the firewall, disable the ability by default, and leave the ActiveX ability in the browser. :)

well, not exactly.

the firewall would provide a layer of security, but there are always ways around it in any decently sized corporate network.

the paradigm used to be that the perimeter firewall was a crunchy protective coating around a chewy center (interior network)...

now, with VPN's and truly massive networks, you need to do more distributed defense- firewalls internally and using the most secure software you can for net communcation (e-mail servers, web servers, constant net processes on the client machines, etc..)

someone wiser than me once said, "Firewalls are a network level response to a software engineering problem." not an attack on you or anything, but if the software was perfectly secure, you would not need firewalls.

you'll never have perfectly secure software, so firewalls are needed, but they would be less important if software was more secure.

Fine, but you can't just throw out ActiveX abilities in the browser is my only argument at this point. :-)

backwards compatibility is always a pain in the ass
from a security standpoint, but it's what MS and
Intel built their empires on.

I love both of those companies; they have helped me make a lot of money. :-)

lol, I am reading up on Intel x86 assembler so I will be better able to understand exploit/shellcode. Gotta know how the other half thinks.

it's kinda crazy that you can kick a P4 Extreme Edition into virtual 8086 mode with real mode flat addressing and have that extremely expensive thing emulate a 20+ year old processor....

hell, there's even a PSP in the memory model that's a leftover from CP/fucking M 80!

put THAT in Microsoft's backward compatibility pipe and smoke it!