Driver updater

Drivers are a soft target, lots are bloated with application features and similar code. Users rarely are in contact with the suppliers fro updates, and more than not, are tempted to load just anything that makes an added proprietary asset functional.

I used to religiously run Secunia PSI (that's now gone...) to update drivers and apps, became more hassle than it was worth, so dumped Windows as a day-to-day email / surfing platform and just use it for development.

Driver and application scanning should be a standard in AV and included in the "free" applications that everybody uses - or else what's the point? I note MS does have a 'malicious software removal tool' functioning in windows updates, and also the availability of checked driver updates via the Windows Catalog.

If the main security boys came on board and did driver scanning for nought, we could also say goodbye to the scam "driver updater" applications that are out there.

Computer security is big business. The only way to win is not to play.

When someone fixes the wiki <ahem!>, probably not a bad idea :-)

Yup there are security advantages to win 10 over previous versions, but also some specific ones that 64 bit has over 32.

[you can probably stop at that comment - what follows is probably way more detail than you need!]

Two 64 bit enhancements that spring to mind are the changes to library function calling conventions to insist that some of the parameters passed in must now happen in a register and not just on the stack[1], and the fact that all that extra address space available will make address space layout randomisation (ASLR) more effective.

[1] Quick bit of background: Down at the machine code level, when you call a subroutine that needs data passed to it, there are a number of ways you can do that. One simple approach is to load up specific CPU registers with data, call your subroutine, and have the function use what it finds in the registers when it gets called. The limitation with this approach is that there is only so much register space, and that limits the amount and complexity of data you can pass in. So a more common way of doing it with x86 architecture code is to push all your parameters onto the stack before calling the function. It can then make a record of where the stack pointer was on entry and access all that data as a positive offset to that location. It can also deliberately shift the stack pointer down a bit to make space to store any local variables that the routine needs. When its done, it restores the stack pointer to its entry position and then does a special kind of return that not only shifts execution back to the calling code, but also strips off the extra crap on the stack that is no longer needed.

So the route to many compromises is the so called "buffer overflow" attack. You basically go hunting for a bit of vulnerable code that does not properly sanitise all its input data. Then work out how to craft an input to it that is "legal" but not exactly what it was expecting. The goal being to get it to copy some data you have supplied into into a local buffer it has created on the stack that is not going to be large enough to hold all the data you have finagled a way of passing in to it. End result is that it tramples over other data on the stack that it should not have. Now in times gone by, this was it game over, since you made sure your extra data could be interpreted as code, and some of it was positioned in just the right place to behave as a return address - pointed at the code you created. So when the routine reaches its end, it cleans up its stack frame and does a "return", but crucially, it grabs

*your* modified return address and makes it jump straight to your malicious code.

Now OSes got wise to that and use features built into modern CPU memory management units to mark the data space allocated to the stack as "non executable". So if you try that trick now days, the moment the flow of execution tries to run code held somewhere that is not in executable address space, it raises a CPU exception that crashes the application and returns control to the kernel.

The way around this was using a hacking development called return oriented programming (ROP). You try the same buffer overflow trick, but this time you can't just jump to your own code. What you can do however, is force it to jump to some existing code that the system does have a marker indicating it's "executable". So you find an entry point (it might not be the actual start of a function - but could be anywhere it it) that will execute something that will do what you want or at least a part of it. With some effort, you can craft an elaborate buffer overflow to fill the stack with a whole bunch of these calls in sequence, so they end up running a chain of "returns" that will implement your exploit but using fragments of stuff already there. (needless to say the black hats can write tools to automate much of this)

The next development in the arms race was the OS using address space layout randomisation (ASLR). Making sure that each time it loads bits of code it tries to do it differently every time, in an unpredictable way. This made it harder for your exploit to just jump to existing stuff because it no longer "knows" where in memory the code it wants to run actually is. The way to hack round ASLR is to either try and reverse engineer the randomisation algorithm (very hard), or it you can run some limited code, go for the brute force approach of just search through all the address space to find a signature of the code you are looking for.

With 32 bit machines there is only so much extra address space to play with, and modern CPUs are so ridiculously fast that a brute force search to find your target code does not take long. With 64 bits that search becomes hard enough that it will be obvious something is going on.

64 bit then has an added road block since it introduces a requirement that some parameter data is passed in registers and not just on the stack. Now you no longer have a way of doing "simple" ROP because you can only manipulate the stack and can't load stuff into registers directly. So now you up the complexity dramatically since you now have to find target bits of code not only to cruft together you exploit, but also load up the register contents you need on demand.