It seems to me...
some of them widely-denigrated "web programs" are tested more thoroughly than Windows. Maybe they need some "full-stack" developers?
A Carnegie-Mellon CERT researcher has discovered that Microsoft broke some use-cases for its Address Space Layout Randomisation (ASLR) mechanism, designed to severely hamper hackers' attempts to exploit security bugs. The programming blunder is simple: as of Windows 8, a flaw in Microsoft's system-wide mandatory ASLR …
>> "sysadmins can set a registry value to force bottom-up ASLR (a wonderful task if you're in charge of a fleet of machines);"
> It makes little difference how many machines under Windows. It takes about 20 seconds to create and apply a GPO setting to everything ...
That's what I thought whilst reading it too; however testing all your applications will take a lot longer than that...
So all applications using mandatory ASLR are affected, but those that have the less secure "opt-in" setting are not.
And no one has noticed this since Windows 8 was released since 2012? Loading the app in a simple debugger or Microsoft's Process Explorer will show the base address and no one noticed?
It boggles the mind. Either a lot less testing has been done on Windows 8, 8.1 and 10 or the tin-foil hat brigade have reason to be paranoid, especially given that it only affected the "mandatory" ASLR.
Probably both. Slurp has be skimping on testing for awhile as evidence by the late alpha releases of Bloat 10 given to the masses, got negligence covered. As a result 'telemetry' is used to getting data from the alpha testers (users) which can get all sorts of juicy details for various doughnut eaters, got malicious covered.
Can you set ACLs on individual fields in a text file?
Security vs maintainability, but I'm afraid you may trust MS to do things right a bit too much.
Or easily audit changes only to specific settings by specific users?
Yup. For years. Text processing and diff came from the Unix world, after all, and it's optimised for it.
Or find a setting without having to parse the file?
So, pray, how will Windows dig up this value? Do they just magically hide in the OS without a convenient file around them to make backup and recovery easy? You do know that a DB is in the end also just files, yes?
"Security vs maintainability, but I'm afraid you may trust MS to do things right a bit too much."
Configuration database solutions have substantial advantages for both.
"Yup. For years."
Oh, so do tell me how you would audit a change to say ONLY Setting 2 including who changed it and before and after values in:
Setting 1 = 1
Setting 2 = 2
Setting 3 = 3
Without resorting to complex third party software like a version control system?
"So, pray, how will Windows dig up this value?"
It uses a btree type database. It doesn't have to parse say white space, comments, or most of the data to find something - it can very rapidly find just the fields needed.
"without a convenient file around them to make backup and recovery easy?"
The Windows Registry is fully transactional with DB log files, snapshots and rollback capability built in.
"Woah! Recommending against revision control, even passively, is extremely bad."
He said version control, not revision control
"If you think it's complex, used at the last resort, then find another job."
It just not needed when you can granular permissions, a concept of transactions / rollback and detailed / integrated auditing like on the Windows registry.
Can you set ACLs on individual fields in a text file?
You can't do that in the registry either. The finest grain thing you can set a permission on is a key. A text file in the user's home directory is the key. That has permissions and ACLs.
Or easily audit changes only to specific settings by specific users?
Only the current user should be able to change a setting in HKCU anyway. Are you saying it's good thing that any user can change stuff in another user's HKU or HKLM instead of an administrator?
Registry ACLs came along later to try and bring some degree of control to the registry free-for-all.
Or find a setting without having to parse the file?
You use a library dedicated to the task. In the Windows world I assume it's much better because you can use a magic unicorn to parse the registry?
That's a Windows 3.11 level legacy solution and Windows moved away from that type of rubbish text file solution for most OS configs a long time ago...
The registry was in Windows 3.
Of all the things you could choose to like about Windows, you chose the registry. It's monolithic, corruptible, binary, is not removed when the app is removed, and even MS would rather you used %APPDATA%. Now excuse me, there's a popup advert vying for my attention saying I need to run a registry cleaner.
"You can't do that in the registry either. The finest grain thing you can set a permission on is a key."
OK, you are correct that a key can contain multiple values, but quite often it is just a single value, and if it does contain multiple values then they will be very closely related together giving a level of granular control simply not available on *nix.
"A text file in the user's home directory is the key. That has permissions and ACLs."
Lol, nothing like it. A typical *nix text config file for a specific function would typically translate to dozens or even hundreds of keys under the Windows registry, and you still have zero auditing of what exactly was changed from what by who like you do under Windows.
"The registry was in Windows 3."
No it wasn't. It didn't arrive until Windows 3.1 - and then only for COM based components. In Windows 3.1 configuration was primarily stored in text files (INI files) - hence the reference to Windows 3.1 having a crap config storage solution.
"Of all the things you could choose to like about Windows, you chose the registry., "
I didn't say I particularly liked it. Just that it's way better than using multiple text files.
"It's monolithic"
Having all your data in one place and in a standard format is a massive advantage over scattered across the system in differing formats!
"corruptible,"
Far more fault tolerant than say a text file - it's transactional with snapshots and rollback.
"binary,"
So is much faster to access and parse than a text file
"is not removed when the app is removed,"
Well that's up to applications. It's of no real consequence even if they don't clean up properly. Registry performance is not size dependent. The registry also has no practical scalability limits you are likely to hit. That's no different from *nix applications leaving config files on the system after removal...
"You can't do that in the registry either. The finest grain thing you can set a permission on is a key. A text file in the user's home directory is the key. That has permissions and ACLs."
Nope. A typical Registry key might be say
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\adsi\Options\excel.exe
or
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\PersistentRoutes
That's WAY more granular than the per file model of Linux.
"You use a library dedicated to the task. In the Windows world I assume it's much better because you can use a magic unicorn to parse the registry?"
The Windows registry is a binary b-tree database so you don't have to read the whole file to find a value so it's way faster and more efficient than parsing a text file, you have single config repository in a specific location, you have improved system integrity due to fully atomic transactions and you have strongly typed data formats.
Or find a setting without having to parse the file?
A person: "grep", "find" (I think.. on windows), text editors have a search, so does explorer.
Software: Get all settings at once, not individually. You're only parsing a file that contains settings for your applications, usually just key-value pairs. Your computer has just parsed several files that are much more complex than most config files when you loaded this page.
Really, the registry is one of the things I hate most about Windows. It's made worse by the fact that regedit is so limited... it still doesn't even support copy+paste, searches limited to a key... but at least you can export it to a text file and re-import it.. It's hardly changed since Windows 95
This post has been deleted by its author
I get the feeling the last time you looked at RegEdit was in 1995.
The whole Windows Registry and Regedit is still a horrible, deliberately and unnecessarily complex way of holding settings. Would it really have been too much trouble to use clear and obvious variable names and values? Obviously the answer is "yes, because we're Microsoft".
Regedit was, is and probably always will be a dog of an interface, and the actual content of the registry is the work of a sociopathic lunatic. Having all configuration data in a single (?) hierarchical database is fine by me, but there's no excuse for wilfully making it risk and difficult to change things for users with admin privileges.
This post has been deleted by its author
Better to have a "Yes" or "No" in a Text file
The only problem with text files is that they are not transactional, neither in part, nor in full. And that there are so many conventions, Security can be easily inherited from that old-school document database, the "filesystem" though.
"Security can be easily inherited from that old-school document database, the "filesystem" though."
Not on a per field or per value basis it can't. If you want to lock down just one setting - you can't easily do that on *nix. It's a very limited and sucky security model compared to Windows.
If you want to lock down just one setting
Why would you want to do that? Seriously, why would you let everyone change settings apart from one?
But anyway, you can just pull different settings from different files, with the permissions you desire. That's how vhosts where configured on a per-user basis.
You can still store the settings in a database, use all the per-field permissions you desire, and spit out the config file from that.
It's a very limited and sucky security model compared to Windows
What makes you say that? The security model is simple, easy to understand, and hard to screw up. Owner, Group, World. That fits most use cases. Anything beyond that, use ACLs.
"Why would you want to do that? Seriously, why would you let everyone change settings apart from one?"
It's very common to want to stop users changing a specific setting. For instance to lock down the security settings tab in IE. Just because you cant do this in *nix doesn't mean it doesn't have a use!
"You can still store the settings in a database, use all the per-field permissions you desire, and spit out the config file from that."
So a version control system. An extra layer to fix what you should have in the first place, and it still doesn't provide granular auditing or ACLs if someone then edits the files directly...
"The security model is simple, easy to understand, and hard to screw up. Owner, Group, World. That fits most use cases. Anything beyond that, use ACLs."
Which on *nix cant be applied to anything smaller than a file. And can't block root (admin) from access. In Windows you have a far more granular and pervasive solution that can properly lock down systems even from admins when needed.
Not on a per field or per value basis it can't. If you want to lock down just one setting - you can't easily do that on *nix. It's a very limited and sucky security model compared to Windows.
If it's really critical it gets its own file, with its own access rights, and that has been done since the days of shadow passwords. Version control is available on any Unix setup, so that's not an issue either, but you then still end up with something that is easy, simple to understand, structured and resistant to errors that would kill a Windows platform.
The whole Registry hairball is far too complex, error prone and sensitive to bit rot for anything that has to stay up for any length of time, and, astonishingly, has not really improved over time. The next issue is that it's actually a database so I need to keep a service online for it.
In *nix I halt that nonsense at file level and only need system resources when a service actually needs to consult the file during startup or when it gets an order to refresh its configuration. Again, simple before complex, and resource efficient to boot.
"Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files."
Great, so that "fixes" the bodge of *nix config files everywhere to a small degree, but it's still not a proper native solution.
"Great, so that "fixes" the bodge of *nix config files everywhere to a small degree, but it's still not a proper native solution."
You and/or other ACs above are suggesting that all the wonderful features of 'modern' Windows are like the glossy paintwork, smart uniforms, flashy food on a great ocean liner ( that someone forgot to actually finish closing all the holes below the waterline )
"You and/or other ACs above are suggesting that all the wonderful features of 'modern' Windows are like the glossy paintwork, smart uniforms, flashy food on a great ocean liner "
Trying us that Linux has better security and configuration storage than Windows is like trying to tell us the Windows ship is sinking when the Linux ship is already at the bottom of the Atlantic...
Trying us that Linux has better security and configuration storage than Windows is like trying to tell us the Windows ship is sinking when the Linux ship is already at the bottom of the Atlantic...
Of course, that's why all serious outfits won't touch Windows for production with a 10ft barge pole. You know, Google, Amazon, Facebook, just the tiny ones who are under constant, 24/7 attack. What got hacked again? Oh yes, banks. Equifax. Others - typically via insider breaches enabled via the wonderful *cough* security *cough* that Windows offers.
But hey, thanks for the laugh.
"You know, Google,"
LOL talking of good laughs, have you seen the sheer number holes and the constant malware problems on Android? And the number of vulnerabilities on their supposed best effort at security Chrome OS?!
"Others - typically via insider breaches enabled via the wonderful *cough* security *cough* that Windows offers."
So you mean like the vast data leaks from Uber, Yahoo, Sony, MySpace, LinkedIn, Maddison, NetEase, Adobe, Badoo, etc. that were all based on Open Source / Linux compromises? Internet facing websites are 4 times less likely to get successfully hacked if they run Windows than Linux.
"And the number of vulnerabilities on their supposed best effort at security Chrome OS?!"
Chrome OS since it's initial release in 2010 has less total vulnerabilities than Windows 10 has since it's release in 2015. What's more interesting is Windows 10 also has a far higher proportion of code execution and privilege escalation vulnerabilities.
Source: cvedetails.com
Microsoft has 75% of on premise servers
.. which don't seem to work that well if recent bank troubles are anything to judge it by, and I note with interest that you're very careful to exclude the numbers that matter*: those systems exposed raw to the Net
over 95% of business PCs
.. which it is just ever so slightly starting to lose to stupid, silly Macs in companies who actually know about numbers and include labour, downtime and breach risk and resource cost when they calculate TCO..
* which suggests you must actually work for Redmond as that has been their MO for decades..
"which don't seem to work that well if recent bank troubles are anything to judge it by"
Erm - but that was a large *nix based back office / batch system that fell over if you mean TSB??
".. which it is just ever so slightly starting to lose to stupid, silly Macs in companies who actually know about numbers and include labour, downtime and breach risk and resource cost when they calculate TCO.."
Well it hasn't impacted market share so far - and companies that care about that generally use Windows via VDI. The cost of Macs on the desktop is way higher. Not to mention the vastly restricted range of software that is available.
This post has been deleted by its author
The cost of Macs on the desktop is way higher. Not to mention the vastly restricted range of software that is available.
No twice, but I already illustrated that. Plus, software is cheap. People are expensive, so if a company puts usability first (less of late, but it's still a considerable distance ahead of Windows) that is a far more beneficial aspect of a platform. As for limited range, you clearly haven't been near the Mac world for a while.
That said, please enjoy Windows. If I support LBGT rights it would be churlish to exclude masochists..
"There are many, many more devices in the world running Linux than Windows. Just saying..."
Sure - must be why I keep reading about Linux based bot nets, Android Play Store malware, etc. etc.
That Windows has a better configuration storage solution and that it's security ACL and auditing model is more capable, granular and in depth than *nix shouldn't be in any doubt to someone with detailed knowledge of both.
Sure - must be why I keep reading about Linux based bot nets, Android Play Store malware, etc. etc.
1 - Linux bot nets: small in comparison to the infestation that is supported by breached Windows machines. I can understand why Linux machines are more desirable though - even for bad guys, uptime matters.
2 - Android <-> Linux, not by a long shot. Android was merely created to get people to submit their personal information to Google without knowing it, something that AFAIK Microsoft pioneered..
"That Windows has a better configuration storage solution and that it's security ACL and auditing model is more capable, granular and in depth than *nix shouldn't be in any doubt to someone with detailed knowledge of both."
I have a detailed knowledge of both, and agree that in some respects the registry is better for the reasons you state above. I also realise that in the real world there's many ways of skinning a cat, and that there's no practical downside to text based config either, provided it's managed properly.
Why I usually prefer deploying Linux over Windows in the real world is that Linux is far more modular than Windows (FUD about monolithic kernels non-withstanding) and I'm able to easily take advantage of this when deploying and managing it (i.e. install just the packages and libraries I need, leave out ones I don't at a far more granular level that Windows offers). It also comes with a hell of a lot less licensing headaches and cost (yes I know what RHEL costs, but I also have a plethora of other options that are cheaper or free - I don't use RHEL).
Also, hey: Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files.
To paraphrase a comedian, as far as I can tell, the tree Windows uses must be derived from a cannabis plant.
"Better to have a "Yes" or "No" in a Text file"
But then you would end up with a mess of text files - probably scattered across the filesystem. That's a Windows 3.11 level legacy solution and Windows moved away from that type of rubbish text file solution for most OS configs a long time ago...
Either way, a BSOD is caused by either a bug in a device driver, faulty hardware or, as AC correctly points out, unsupported hardware. That a particular OS setting delays the time it takes before you hit a BSOD is neither here nor there: you haven't solved anything.
The only sane options (in no particular order):
1. Use Linux
2. Upgrade to Windows 10
3. Change hardware until you find something that works
Run various benchmarks that stress CPU (SuperPI) and memory (sysinternals might have something, can't remember) and you'll probably be able to reproduce your BSOD quite readily. Or it is something completely different, like a naff NIC device driver.
I used to be a Win7 holdout too. I upgraded to Win10 and never looked back. Win10 is a noticeable improvement and I highly recommend it.
Insisting on running an OS that is on the fast track to obsolescence strikes me as a decidedly bad strategy.
"running an OS that is on the fast track to obsolescence strikes me as a decidedly bad strategy
Perhaps you should practice what you preach."
Erm, but doesn't Windows 10 have the record for fastest OS take up ever, and has over 600 million installs? Doesn't sound like it's going to be obsolete any time soon.
This post has been deleted by its author
Win 10 is actually a major security improvement over 7...
And unexpected behavior in a non-standard ASLR configuration isn't exactly the end of the world or a huge security lapse. I suspect the reason this wasn't noticed earlier is simply that there isn't much software left that's not built with DYNBASE (ASLR opt-in)...
And the ONLY issue here is a user interface issue in Exploit Guard - nothing else.
"Hey, won't this change mess up some ASLR stuff?"
"That'll be the least of the problems with this bag of shit."
"Don't you think people will notice?"
"That would be like noticing a slight yeast taste in beer after filtering it through a polyester couch after a house fire."
You forgot the bit where someone said "but with these new tiles that replace menus, and this fantastic app store, not to mention the charms on the right, it'll bring about such a revolution in ease of use, obviousness and productivity acceleration that people will love us too much to care about any security aspect we've inadvertently forgotten about in the meantime".
This was followed by the ceremonial drinking of the kool-aid.
More like:
"I'm just changing ASLR so that it's more obvious what the registry settings do"
"OK. Just make sure the EMET team know."
...sometime later...
"The EMET team has been disbanded because EMET is no longer a product. Didn't we have some dependency on them?"
"Yes, but if EMET is dying it can't have been important."
So, what with Intel chippery leaking secrets and Win8+10 not being genuwynely secure, shall we start the downgrade to Win7 on the desktop and OS/2 Warp LAN server (on Intel Pentium 2's) on the server side then?
At least the networks will be nippy and fast enough until somebody finds a backdoor in routerland...
Windows has grown an Arm variant quite recently,
Yes, one that restricts the Win32 API and is trapped a range of hardware that is being neglected by MS. Didn't work for Surface RT and isn't working for Windows Phone.
When they come out with something that's more than vapourware perhaps we can say that Windows isn't trapped on Intel.
" I sort-of assume that any exploit in CPU land would still have to understand the OS"
Nope - this has a separate CPU and firmware. Whilst it can access the main CPU / RAM it doesn't have to.
"Yes, one that restricts the Win32 API and is trapped a range of hardware that is being neglected by MS"
You don't seem to know what you are talking about. Win32 is now fully supported on ARM by emulation. Microsoft have had Windows server running internally on Arm since 2014.
This post has been deleted by its author
"That applies to any OS btw."
I'm curious to know if it does. I sort-of assume that any exploit in CPU land would still have to understand the OS running on top in order to exploit it. So if you're running something obscure you might well be safe. Sure it's security through obscurity, but obscurity worked for Linux for years.
... and Windows manages to use more than 1Gb idle after a week of heavy load ... in fact, it was using 8Gb and as much was used in the page file, even after closing every single little gui app ... no, I only had a single non-MS service running, which was probably using 128Mb of RAM ....
Address Space Layout Randomisation (ASLR) mechanism, designed to severely hamper hackers' attempts to exploit security bugs.
The OS owns itself all by its own, no need to make it any worse ...
DISCLAIMER: Linux and OS X user here, and OS X gave me the "bad habit" of rebooting every 6 months ... Linux never had a problem with that ...
PS: The frequent notepad.exe patches that force a reboot or two are bad enough already ....
"and Windows manages to use more than 1Gb idle after a week of heavy load "
That's meaningless if it's not under heavy load and you have free RAM. Windows will cache everything it can.
"... in fact, it was using 8Gb and as much was used in the page file, even after closing every single little gui app"
So if it's in the page file it's not using RAM. Memory use is not just about open apps - Windows will cache and preload stuff if it has free resources...
This tells that those people are not so much interested to offer security as to offer the false sense of security, which is more effective to dazzle consumers. We see a similar phenomenon in the case of biometrics that is said to offer higher security but actually only offers higher convenience at the sacrifice of security.