Microsoft Using Open Source?

[Gizmo]

MS using Open Source in Vista? Well, sort of. It seems that Microsoft is incorporating a technology called Address Space Layout Randomization into Windows Vista. This feature exists to help prevent attacks against the OS, but is not an MS innovation. It is, in fact, widely used in the open source community, being implemented in OpenBSD as well as some 'hardened' patches for Linux.

Hmm.........I wonder if MS lifted some source code, or if they just used the idea? With MS, it's hard to tell.....

[madcatmk3]

probly took some of the code, but heres the thing, despite this making the OS more secure people will just figure out a way around it...

[skool h8r]

But isn't this going to make it harder for genuine application developers to make applications work? For example, does this mean that ToIP or AJet³ won't work correctly as they require use of DLL's?

as one of the chuckle brothers would say: oh-dear oh-dear.

[madcatmk3]

mabey mabey not, well have to wait for it to come out.
Also I've bean wondering for a while whats the differance between an windows OEM and the Retail, does the retail inclide office or something?

[Favu]

It would seem to me that address space randomisation would be randomisation of where in the computer's RAM things are stored, rather than not using .dll s.

This would make it harder to overwrite things in the memory, because you don't know wher ethey are

well, thats what I *think* because I don't know

[danrok]

Originally Posted by madcatmk3

mabey mabey not, well have to wait for it to come out.
Also I've bean wondering for a while whats the differance between an windows OEM and the Retail, does the retail inclide office or something?

OEM is just the disk and not much else.

Retail comes with some manuals - very useful if you are short of fire wood.

[madcatmk3]

Originally Posted by danrok

OEM is just the disk and not much else.

Retail comes with some manuals - very useful if you are short of fire wood.

so thats what the extra $100 gets you?

[skool h8r]

Originally Posted by madcatmk3

so thats what the extra $100 gets you?

put simply, yes. Oh yeah, you get the packaging as well. Woo, lovely boxes.

[madcatmk3]

One thing I learned since I started building computers is the hardest part is not configuring one, or building one but getting all the parts out of the packaging.

[Gizmo]

Originally Posted by danrok

OEM is just the disk and not much else.

Retail comes with some manuals - very useful if you are short of fire wood.

OEM is less expensive and comes with different licensing terms.

Among other things, an OEM version of software is only licensed for the hardware it comes installed on. If you buy a machine with an OEM version of Windows and then replace the mobo (for whatever reason), even if you replace the mobo with an identical replacement from the same manufacturer, you are technically required to buy a new Windows license. As I understand it, even if you just buy a new hard-drive to replace the existing one, you have to buy a new Windows license. In most cases, this is not enforced, and in the vast majority of cases is unenforcable as a practical matter ANYWAY. (NOTE: At least SOME Gateway machines encode hardware info into the Windows installation CD somehow: change the mobo and Windows will refuse to come up, telling you that you have an illegal version of Windows.)

An OEM version of Windows MUST BE SOLD WITH HARDWARE (NewEgg skirts this requirement by selling it with a mouse).

Vendors of OEM versions are required to provide Level 1 support. If you call MS with a problem on your OEM version, they will likely tell you to contact your vendor for support.

There are some very, VERY good illegal Windows OEM versions out there being sold for $80 and less for WinXP Pro (I know, as I appear to have three of them, according to MS). The cheapest LEGAL copy of Windows XP Pro OEM Full (not upgrade) I have seen is about $120.

[Gizmo]

Originally Posted by skool h8r

But isn't this going to make it harder for genuine application developers to make applications work? For example, does this mean that ToIP or AJet³ won't work correctly as they require use of DLL's?

as one of the chuckle brothers would say: oh-dear oh-dear.

No, because when you use a DLL you actually do two things (depending on the environment you are using, you may have to do these explicitly, or they may be done for you behind the scenes).

1) Call LoadLibrary() with the filename of the DLL to actually load the DLL. This returns a handle to the DLL resource.
2) Call GetProcAddress() with either the name of the function in the DLL, or the ordinal number of the call in the DLL, and the handle to the DLL resource. This returns a pointer to the actual function address within the DLL, which you then use to make the actual call.

With C++, if you use static linking, the above magic is handled in the linker. If you use dynamic linking, then you have to do it yourself, with the exception that there may be some vendor specific class libraries supplied as part of the development environment that contain the necessary fixup code already built into the environment.

For other languages, like VB, and pretty much anything that runs on the .NET CLR, all of the linking stuff is done behind the scenes dynamically.

In any case, all this does it make it a little more difficult for the malicious coder to tear up things. Instead of just KNOWING that a certain address in memory will point to a particular function in a particular library, they now have to go by the numbers and do what I described above. This makes the code a little bigger, and a little more tedious to write, but if they've got the smarts to figure out that a function lives at a particular address, they've got the smarts to work around this.

[dsio]

From memory, didn't microsoft directly use a large amount of code lifted from BSD? I remember someone telling me that even ping.exe, winsock.dll, and a heap of other stuff was borrowed.

[Aedan]

Originally Posted by gizmo

2) Call GetProcAddress() with either the name of the function in the DLL, or the ordinal number of the call in the DLL, and the handle to the DLL resource. This returns a pointer to the actual function address within the DLL, which you then use to make the actual call.

When you are writing exploit code under windows, it's handy to be able to call GetProcAddress. Of course to call it, you have to know the address in memory to call. In the past, I've done this by building a table of DLL entry points based on the OS and service pack. I can do this, because GetProcAddress always has the same entry point in memory for a given OS/service pack. Once I have GetProcAddress, I can use that to find out other entry points that I need.

With a bit of careful work, it's possible to write exploit code in less than 200 bytes that will cause the host to connect outward, retreive another program from across the internet, launch that program and then clean up nicely (call ExitProcess as opposed to crash) afterwards.

[Aedan]

Originally Posted by dsio

From memory, didn't microsoft directly use a large amount of code lifted from BSD? I remember someone telling me that even ping.exe, winsock.dll, and a heap of other stuff was borrowed.

Many IP stacks use BSD code - the BSD license allows you to do that, as long as you acknowledge where the code came from.

Prior to NT 3.5, the MS stack was based on another product which was definitely based on BSD. However, NT 3.5 featured a re-written IP stack, so the stack itself is not BSD based. However, utilities such as ftp which are substantially the same are based on the BSD code. That's why they have the "Copyright (c) 1983 The Regents of the University of California. All rights reserved" in them. After all, a working command line FTP client works, so why change it?

The same goes for Apple, HP, IBM, SCO, SGI, Cray and others. If you've ever wondered why BSD code ends up all over the world, it's because they don't have such a stupid license agreement as the GPL.

[skool h8r]

I use Delphi so i suspect it'll all be handled for me.

[Aedan]

Delphi is likely to handle that for you. For example, when you call an entry in external DLL, Delphi will have to load the library and then find the correct entry point for that entry. If you've never dealt with LoadLibrary and friends, then your environment is dealing with it for you.

Wonder how this will affect DLL injection however...

[Gizmo]

Originally Posted by Áedán

Wonder how this will affect DLL injection however...

I wouldn't think it would change it, beyond simply having to know what address the DLL is loaded at.

The thing I am curious about is how it will affect program load times. Application developers who use custom DLLs can rebase the DLL address so that each of their custom DLLs has a unique address space. This is desirable in that it allows the OS to simply load the DLL and then go, because there are no address conflicts between the DLL being loaded and the DLLs already loaded in memory. If you load a DLL that has an address conflict with a DLL that is already loaded, you end up with the system having to do address fixups on the DLL before it can be used.

With this scheme, it would seem to me like that performance enhancement is gone right out the window. 'Course, with today's CPUs, and given the fact that it only happens at the time the DLL is loaded, it probably isn't that big of a deal, but still.....