So, because someone throws a new cool Apple feature name out there, I should just accept that it is the ultimate security feature that will magically distinguish between malicious and legitimate writes to sudoers?
The description says that it will protect the *binaries*. Reading comprehension? (hint: sudoers is not a binary)
10.11 has a new SELinux-like 'rootless' security model that should mitigate against any privilege escalation attack like this. Odds are it was naturally immune..
That's interesting. This is waht I have been able to find from Apple on the feature (now called "System Integrity Protection"):
"System Integrity Protection
A new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted."
Hardly a new "security model". And from that description - no it would not have mitigated this attack.
Sounds an awful lot like Windows File Protection (later renamed to Windows Resource Protection). Welcome to 2004!
Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?). Of course, once you are root then you can do things like modify firmware and boot settings and hide inside the kernel...
Spot on. If I was a bad guy (I'm only a little bad) this is *exactly* how I would create an attack.
The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?)
That part in particular highlights the problem with setuid.
It is, in effect, a deliberate hole in the security boundary: The mere existence of the setuid facility means that you can *never* audit the security policies (access rights) and be confident that they truly reflect the rights and restrictions of users.
Auditor: "Who can access this file"
Admin: "Easy" (ls in the directory), "User1 can write and users in the group "group1" can read it.
Auditor: "And no-one else can read or write the file, not even root?"
Admin: "What do you mean, of course root can read and write the file, root can do anything. This is Unix, d-oh!".
Auditor: "Ok. Who can run as root, then? I need to have an exhaustive list, you see. The insurance company needs the list to assert the risk and calculate the premium"
Admin: (sighs, looks up in sudoers and su) "The user admin1 and users in admingroup1 can run as root".
Auditor: "And no-one else can run as root? What about that setuid bit I've heard of?"
Admin: "yes, ok, a setuid root utility can run as root, I knew that. But I have those covered. I run a report every week which lists all of those utilities with the setuid bit that are owned by root. We accept only those utilities that we know. Trust me"
Auditor: "Ok then. So back to this file, how can you document to me that - say - this 'cmsagent' utility cannot access the file, now that we know it is setuid root?"
Admin: "What do you mean, I installed cmsagent myself, I'm pretty sure that it only allows remote users to access documents in the CMS system"
Auditor: "But how do *I* know that? The operating system does not protect the resource against root abuse?"
Admin: "No - this is Unix. I know what I am doing. Trust me. I have access to the source code, if you want to see what it can do".
Auditor: "Ok. I don't know how to read code, so I need to have one of our code auditors look at all the source code then. Assuming that, how do I know that the binary present on this system is the compilation of the source code you will give me?"
All of this because of a bad design decision. In other operating systems (with no all-powerful root and no setuid), the DACL of a resource *does* reflect who can access the file.
SELinux, apparmor etc are ways to add (yet another) security context with proper security boundary.
You need to learn to distinguish between vulnerabilities and exploits. An *exploit* (the "installer" in this case) takes advantage of a *vulnerability* (the privilege escalation bug) to perform the attack. The underlying vulnerability exists regardless of the exploit.
You focus on the exploit and (incorrectly) claim that it is unlikely to work. That's beside the point, however, as there are many *other* ways to exploit the vulnerability, where a code execution vulnerability in a browser, email client, facebook app or whatever can be combined with this vulnerability to create true drive-by exploits.
I took issue with the dismissal of this bug as "just a privilege escalation" bug. Privilege escalation bugs are *serious* and critical vulnerabilities.
You do not need an installer to exploit this vulnerability. A simple execution bug in Firefox (last version patched 4 of them, as did practically every version before that) or a sandbox escape bug in Chrome/Safari (more rare) will get you pwned should an attacker choose to create an exploit.
As an apologist you are looking for a way to explain away the seriousness of the bug. That's the wrong (and dangerous) way to think about it. There are many attackers with tons of creativity who are ready to leverage a privilege escalation bug in any way they can.
You cannot possibly cover all those scenarios. That is why we need OS vendors and software developers to maintain and respect security boundaries: Walls where as few as possible well-defined gateways, where each gateway is controlled by transparent policies that makes it easy to audit what can pass through the gateway and (preferably) why.
In this case a piece of the wall crumbled, which means that you must now consider the risk that all the bad guys on the outside can venture in to the protected inside and do whatever they like. You have identified one bad guy on the outside (the installer) and claim that he can be controlled. What about all those that you have not identified?
It's a privilege escalation exploit, so an attacker would already need shell access on your computer to get something done.
No shell access needed. A code execution bug in Firefox, Safari or Chrome (or whatever browser or internet-facing software you use) and the attacker is a local user. Especially Firefox does not have a sandbox, so a bug gives the attacker free reign. With this bug he can become root on your kit. That is bad. Blended attacks are the *norm* now - not the exception. Sometimes they are called "attack coctails" when they try multiple vulnerabilities to get foothold and then use privilege escalation bugs like these to break out of sandboxes or gain root.
Every OS has privilege escalation vulnerabilities, because it's much harder to close all the holes when you allow someone to execute arbitrary code on a system.
Unix and Linux with the braindead SUID/setuid design are especially susceptible to privilege escalation. The design is akin to the security model of ActiveX: You let someone gain privileges far beyond what is necessary and then hopes he is well behaved and - crucially - cannot be fooled to use those privileges in nefarious ways. Well, bugs is one way to fool a SUID process to do something wrong.
SUID/setuid breaches the security boundary of the *nix security model. Once a process becomes root there is no policy that constrain what the process can do*.
* (absent kludges like apparmor, SELinux that are bolted on with separate security policies).
That said, this is a particularly braindead bug from Apple, and it is worrisome because it shows they aren't thinking about security, or don't have proper processes in place to ensure the system stays secure. Their programmers should have known better than to create that kind of environment variable so lightly.
Again, the trap is in the basic Unix design. A SUID process executes in the environment where it was launched, but with privileges of the file owner (typically root). That means that *anything* from the user environment is potentially an attack vector. In this case it was as simple as environment variables. So the tables turn, and now the developer must *explicitly* guard against malicious injections rather than coding to a well-defined contract where parameters are explicit. Not to mention that the developer may not even be aware that someone will change the executable to SUID or just invoke the executable as a tool from another SUID executable (example: sudo).
But not all and you can't prevent MS from changing your shit with forced updates. Or are you using Enterprise?
Yes all. And you cannot prevent Apple from changing your shit when they update OS X. What makes you think that MS will use Windows Update to change settings? They have never done so before, and have not indicated that they reserve that right for the future.
I don't understand why people think this sort of thing doesn't happen. It has been *publicly disclosed* that this level of spying takes place. The NSA was caught red-handed putting spyware in the firmware of routers being sent overseas...why in the world wouldn't they partner with Microsoft to inject spying software into Windows?
It would be naïve to think that NSA do not try something like this. But what would Microsoft gain? They would risk their entire revenue, for what? Favors of the NSA? Microsoft - and any other vendor with business in US - will have to comply with lawful orders. Unfortunately, FISA decisions are not public. But Red Hat or any other vendors would have to comply with the same FISA orders.
That isn't the issue. The issue is YOU being able to share MY WiFi key because I was dumb enough to let a Windows 10 user on my WiFi network. This is akin to me giving you the keys to my house so you can housesit, and you getting a hundred copies cut and distributing them to a bunch of people you know.
So wrong.
If you *tell* someone your WiFi password *then* there's nothing stopping them from sharing it with whomever they want. So do not do that. Not if he brings OS X or Linux or Windows.
If you want to allow some friend onto your network but not allow him to share your network with others, then *you* tap in the password at his computer when it connects. On OS X or Linux or Windows. That what you would do today, and that's what you would do when your friends brings a Windows 10. On Windows 10 simply DO NOT CHECK the "share" checkbox. It is off by default. Your network will not be shared.
Nothing has changed. Neither your network nor your password will be shared with anyone. Your friend cannot go into settings and share the network after the fact - it has to be done when connecting.
But if *you* connect to some network which you would like to share with your friends, you can check the "share" checkbox. When you do that, your password will be stored encrypted in Microsofts servers. When one of your friends (if you share with - say - Facebook friends) is in range of that network, his Windows 10 computer can engage the network. The network will issue a challenge with must be hashed using the password as salt, and the hash returned. Modern password auth works like that to avoid sending passwords in cleartext. This means that the *actual* password hash is a one-time hash computed from the challenge.
The computation of the hash is performed on Microsofts servers, and your actual password is NEVER available on your friends computer - not even in encrypted form - only the challenge response hash. Your friends computer must obtain the response to the challenge from Microsofts servers - and when doing so it must prove that it belongs to a friend of yours.
Furthermore, Windows 10 which connects to a network in this way will *not* allow access to other devices on the network except for the internet gateway. I.e. it can only be used for Internet access - nor for local file or media sharing.
Even with disk cleanup removing redundancies in the winSXS folder, it can still swell to be over 12gb in size.
There are no redundancies in the WinSxS folder. That's actually the point of WinSxS: It is a "repository" of sorts where all OS files are stored and the actual files are merely hard links to the file in WinSxS. That way, even if a file is placed in multiple places, it is still only a single file.
To be able to *uninstall* updates, WinSxS does hold on to the "old" files. That way, if you roll an update back or uninstall a component, Windows will simply change the hard link or delete the linking file. If you do not want to be able to roll back to a previous state, you can always clean up by discarding the "old" service pack files by issuing the command "dism/online/cleanup-image/spsuperseded"
So to summarize: as a user, you can sometimes write to EFI memory.
That's currently all there is to it. There's no rootkit, there's no malware, etc. Just this space where you can hide and survive an OS wipe and reinstall.
Yes - it is a vulnerability for which there is no exploit published (yet).
This vulnerability is serious, as it allows an attacker to permanently infect the Mac *firmware* and gain control each time the Mac is booted - even if you nuke and reinstall OS X.
You may try to dismiss this as "still needs another vulnerability". Another vulnerability or even a social engineering attack, evil maid attack will all suffice. This one can be used to take permanent, undetected residence on successfully exploited macs.
I am nervous as this feels like early 2008 all over again.
Don't be. In 2008 there was a real risk that banks would fall like dominoes. When talk started about a possible Greek default in the first round, the same concern was there: That a lot of European banks had so deep loans to Greece that a Greek default would cause the banks to start toppling and cause a widespread crisis in Europe.
This time, the other European states (notably Germany), ECB and IMF have largely taken over the "bad debt" from the banks. Which means that Central banks, ECB and IMF will have to write off some loans if Greece defaults, but banks and the financial system is largely insulated.
Last time, Greece used the threat of throwing Europe into a deep financial crisis as negotiation leverage. This time, that threat has been neutralized and that is why you see other European leaders standing more firm on Greece owning up to their situation.
Talk about WWII reparations is NOT owning up to the problems that created this crisis in the first place. Greece were about to be exposed as insolvent before entering the Euro. But getting into the Euro meant cheaper loans and could postpone the point where they ran out of money. So Greece at the time lied and cheated their way into the Euro: They "mistakenly" left out the state obligations for pensions as obligations (should have counted as long-term debt). They got in and got access to cheaper loans. But they did not mend the broken system, and here we are.
And that was new loans AT INSANE RATES. Last time I've checked check dept per citizen numbers, Greek was roughly on the level of Germany. But interest rates they are paying (and that mostly to German banks), oh my goodness:
Interest rates reflect the lenders perceived risk of not being able to retrieve the loan on time or at all.German citizens are vastly more productive than Greek citizens.
If I were to lend 10.000 euros to someone, I'd have a better chance of having that loan paid in full from a German citizen living and working in Germany than from a Greek citizen living and working in Greece. That does not mean that I would not lend to Greece, but it means that I would take a higher interest rate to compensate for the risk.
It is not a diabolic German plan to put Greece down. It's just economics.
So this is just a sys-admin tool. Not a general purpose scripting language.
It is a general purpose scripting language.
An object-oriented general purpose scripting language with a number of features that makes system administration easier.
One example is DSC. It is a scripting language that can use the DSC *platform* to make sure that target systems are all configured the same way, albeit each with different parameters.
Another example is workflows. Wake me up when bash or python can start a script that can survive system restarts and pick up and continue from where it was when the system restarted, complete with state, variables etc.
But if I am going to learn something new, what advantages this powershell has that python does not? Cygwin + bash is cross platform enough for me to switch between ssh windows in linux boxes and my windows desktop.
Desired State Configuration (DSC) that FTFA was about, is definitely one such thing that PowerShell has that python has not. DSC is a *declarative* description of the configuration you want for a target system. You should think more in line of Chef or Puppet than Python. PowerShell DSC for Linux actually *uses* Python.
The idea is that you use PowerShell to define a data structure (much like a Ruby hash) that describes the configuration of the node. DSC will itself resolve dependencies. If you require a feature DSC will ensure that the feature is installed - much like a package manager - but it actually interacts with the package manager. What package managers do not do is to configure the products once they are installed. This could be connection strings, IP addresses, user accounts.
PowerShell DSC for Linux has "resources" for file system, user accounts, text file content, package managers (Yum, Apt, Zypper), scripts, daemons, ssh keys and more. You use those resources to describe how you want a system to look - like a Chef recipe. The resource description can be parameterized (it is just a PowerShell function and can take parameters like PS functions) so that the same resource description can be used for multiple targets with slightly different values.
Once applied, DSC will ensure that the target is set up so that it matches the target. From there on it can also report on drift (e.g. more users created, files deleted/changed etc) and can warn about it and automatically bring the node back to the desired state (undoing the drift).
Wordy is the key issue, look at your average unix app generally all the flags can use a short - or a long -- for the same function.
How about if the unix app allowed only the long form option names - but allowed them to be abbreviated as long as the abbreviation was unambigous? (That's what powershell does)
PS forget that 30+ years of unix shell to near perfection and rolled their own verbose and obtuse creation
That why we still code in assembler and don't use those modern touch screens. Oh wait... (lalalalalalalal! -- fingers in ears, eyes firmly closed)
They will not get bash to work well under windows. The problem is the brain-dead and overcomplicated NTFS permission system. There is no way to get that handled without just as over-complicated and brain-dead "special" tools.
Yes, there is no concept of SUID/setuid on Windows. So there's no sudo "happy go lucky".
1. What is awkward with string parsing? Is this shell aimed at _incompetent_ people?
No, PowerShell is aimed at admins who want *robust* scripts - both the ad-hoc ones they whip up as well as the ones they choose to save. String parsing is extremely brittle, and most bash shell scipters do it the insecure and brittle way because it is easier.
String parsing is often thrown off if presented with unusual characters in file names, if executed in locales where dates and numbers are both generated and parsed different, etc.
2. And that works how on Linux?
OMI is available on Linux. Read the FTFA
3. An IDE in a Shell? Is the syntax so bad that you need an IDE? Or is this another effect of being aimed at incompetents?
You're the incompetent one. There's is no "IDE in a shell". The ISE *is* the shell - much like if you did bash scripting from emacs. The difference is that the ISE will provide you with intellisense (automatic suggestions), help, syntax highlighting, snippets, multiple script panels, integrated source-level debugging (complete with breakpoints, variable inspection etc) and even a command "builder".
4. Aehm, know any mainstream modern shell that does _not_ have excellent documentation?
Most *nix shells have good documentation. PowerShell has good documentation as well. All of the cmdlets have syntax descriptions (automatically generated from metadata), description and multiple examples. In PowerShell even user-defined functions, cmdlets and script files can have the same level of documentation. Comment based help (look it up) makes it super easy to document scripts and functions. And the auto-generated syntax diagrams and parameter descriptions also work for your own script files.
5. Seriously? I found the command syntax exceptionally awkward and badly thought out. I am back to a cygwin console for most things.
PowerShells command syntax is extremely consistent. Cmdlets are *always* of the verb-noun form, and there are only about 40 or so standard "approved" verbs. Parsing of the command parameters is the responsibility of the *shell* not of the commands like in *nix shells. Hence, all commands follow the same convention with no strange outliers like e.g. dd. Parameter names are always "long" - but can be abbreviated as long as the abbreviation is unambigous.
Why is it that when I look at wikipedia , they show all the various counters more or less in agreement, except netapplications which vastly overcounts IE and undercounts Chrome, android and safari?
Maybe because Net Applications is the only counter that tries to correct for known skewed sampling. Net Applications uses CIA internet usage data (how much of the population in each country has access to the Internet) to estimate absolute numbers for each country based on the measures distribution and the "Internet" population number. Net Applications is perfectly honest and upfront about this.
The other counters just report whatever stats has been collected. They also are perfectly honest and upfront about this.
Both correcting and not correcting may leave errors. Be your own judge.
But there's a perfectly good explanation as to *why* the numbers seem not to agree: They do not even claim to illustrate the same thing. Net Applications tries to create a number for "true" global distribution (and risk errors), the others do not even claim to compute such a number. In theory you could take the numbers from, say statcounter, by country and extrapolate the absolute number per country, sum them up by browser and calculate a number similar to net app. Could be interesting to see.
Also, be aware that there is also great popential for skewed demographics between the counters, not to mention the fact that Net Applications tries to measure unique visitors (discarding repeat visitors within a month) while most of the others just report page impressions. If for instance users of Chrome are more active on the 'net than users of IE, chrome would have a bigger share of page impressions than they would of unique visitors. There is no "right" in this: It all depends on the question you ask: If the Q is "which browser is the most popular?" you would look at unique visitors. If the Q is "which browser is used the most?" you would look at page impressions.
Why is it that of all the various counters netapplications is the one most often quoted, even though they appear to be using a bad methodology.
Maybe because they use the *least bad* methodology. The others do not even *pretend* to estimate global usage. They may report what *they* see of usage globally, but none of them claim to know how many users there are in each contry.
Climbing Everest is stupid, irresponsible, dangerous, pointless task for people with severe mental problems like constantly needing approval from others or pathological levels of arrogance or constantly feeling inadequate. So I have to wonder how he even got that job at Google with the personality of an Everest climber.
He was privacy director at Google. Hello? Being away climbing mountains 11 months a year was a core qualification.
1) Are you saying that the signature does not cover the entire download, and that an attacker could supplement or exchange content of the download without invalidating the signature, and have the injected code execute when the user starts the app?
2) Sounds bad.
3) Sounds bad
4) That a signature-based AV engine is only effective when attacks have been reported, analysed and a has been signature developed is bloody obvious. All an AV engines is good for is herd immunity. Which is sorta ok, except that they are peddled as the most important security product *you* can use. Some AV engines more advanced than XProtect use heuristics (or se they claim) but I have to admit that I am *really* sceptical about the claims of the effectiveness.
Slashdot Mirror
So, because someone throws a new cool Apple feature name out there, I should just accept that it is the ultimate security feature that will magically distinguish between malicious and legitimate writes to sudoers?
The description says that it will protect the *binaries*. Reading comprehension? (hint: sudoers is not a binary)
10.11 has a new SELinux-like 'rootless' security model that should mitigate against any privilege escalation attack like this. Odds are it was naturally immune..
That's interesting. This is waht I have been able to find from Apple on the feature (now called "System Integrity Protection"):
"System Integrity Protection
A new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted."
Hardly a new "security model". And from that description - no it would not have mitigated this attack.
Sounds an awful lot like Windows File Protection (later renamed to Windows Resource Protection). Welcome to 2004!
Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?). Of course, once you are root then you can do things like modify firmware and boot settings and hide inside the kernel...
Spot on. If I was a bad guy (I'm only a little bad) this is *exactly* how I would create an attack.
The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?)
That part in particular highlights the problem with setuid.
It is, in effect, a deliberate hole in the security boundary: The mere existence of the setuid facility means that you can *never* audit the security policies (access rights) and be confident that they truly reflect the rights and restrictions of users.
Auditor: "Who can access this file"
Admin: "Easy" (ls in the directory), "User1 can write and users in the group "group1" can read it.
Auditor: "And no-one else can read or write the file, not even root?"
Admin: "What do you mean, of course root can read and write the file, root can do anything. This is Unix, d-oh!".
Auditor: "Ok. Who can run as root, then? I need to have an exhaustive list, you see. The insurance company needs the list to assert the risk and calculate the premium"
Admin: (sighs, looks up in sudoers and su) "The user admin1 and users in admingroup1 can run as root".
Auditor: "And no-one else can run as root? What about that setuid bit I've heard of?"
Admin: "yes, ok, a setuid root utility can run as root, I knew that. But I have those covered. I run a report every week which lists all of those utilities with the setuid bit that are owned by root. We accept only those utilities that we know. Trust me"
Auditor: "Ok then. So back to this file, how can you document to me that - say - this 'cmsagent' utility cannot access the file, now that we know it is setuid root?"
Admin: "What do you mean, I installed cmsagent myself, I'm pretty sure that it only allows remote users to access documents in the CMS system"
Auditor: "But how do *I* know that? The operating system does not protect the resource against root abuse?"
Admin: "No - this is Unix. I know what I am doing. Trust me. I have access to the source code, if you want to see what it can do".
Auditor: "Ok. I don't know how to read code, so I need to have one of our code auditors look at all the source code then. Assuming that, how do I know that the binary present on this system is the compilation of the source code you will give me?"
All of this because of a bad design decision. In other operating systems (with no all-powerful root and no setuid), the DACL of a resource *does* reflect who can access the file.
SELinux, apparmor etc are ways to add (yet another) security context with proper security boundary.
NO, you miss the point....
You need to learn to distinguish between vulnerabilities and exploits. An *exploit* (the "installer" in this case) takes advantage of a *vulnerability* (the privilege escalation bug) to perform the attack. The underlying vulnerability exists regardless of the exploit.
You focus on the exploit and (incorrectly) claim that it is unlikely to work. That's beside the point, however, as there are many *other* ways to exploit the vulnerability, where a code execution vulnerability in a browser, email client, facebook app or whatever can be combined with this vulnerability to create true drive-by exploits.
I took issue with the dismissal of this bug as "just a privilege escalation" bug. Privilege escalation bugs are *serious* and critical vulnerabilities.
You do not need an installer to exploit this vulnerability. A simple execution bug in Firefox (last version patched 4 of them, as did practically every version before that) or a sandbox escape bug in Chrome/Safari (more rare) will get you pwned should an attacker choose to create an exploit.
As an apologist you are looking for a way to explain away the seriousness of the bug. That's the wrong (and dangerous) way to think about it. There are many attackers with tons of creativity who are ready to leverage a privilege escalation bug in any way they can.
You cannot possibly cover all those scenarios. That is why we need OS vendors and software developers to maintain and respect security boundaries: Walls where as few as possible well-defined gateways, where each gateway is controlled by transparent policies that makes it easy to audit what can pass through the gateway and (preferably) why.
In this case a piece of the wall crumbled, which means that you must now consider the risk that all the bad guys on the outside can venture in to the protected inside and do whatever they like. You have identified one bad guy on the outside (the installer) and claim that he can be controlled. What about all those that you have not identified?
It's a privilege escalation exploit, so an attacker would already need shell access on your computer to get something done.
No shell access needed. A code execution bug in Firefox, Safari or Chrome (or whatever browser or internet-facing software you use) and the attacker is a local user. Especially Firefox does not have a sandbox, so a bug gives the attacker free reign. With this bug he can become root on your kit. That is bad. Blended attacks are the *norm* now - not the exception. Sometimes they are called "attack coctails" when they try multiple vulnerabilities to get foothold and then use privilege escalation bugs like these to break out of sandboxes or gain root.
Every OS has privilege escalation vulnerabilities, because it's much harder to close all the holes when you allow someone to execute arbitrary code on a system.
Unix and Linux with the braindead SUID/setuid design are especially susceptible to privilege escalation. The design is akin to the security model of ActiveX: You let someone gain privileges far beyond what is necessary and then hopes he is well behaved and - crucially - cannot be fooled to use those privileges in nefarious ways. Well, bugs is one way to fool a SUID process to do something wrong.
SUID/setuid breaches the security boundary of the *nix security model. Once a process becomes root there is no policy that constrain what the process can do*.
* (absent kludges like apparmor, SELinux that are bolted on with separate security policies).
That said, this is a particularly braindead bug from Apple, and it is worrisome because it shows they aren't thinking about security, or don't have proper processes in place to ensure the system stays secure. Their programmers should have known better than to create that kind of environment variable so lightly.
Again, the trap is in the basic Unix design. A SUID process executes in the environment where it was launched, but with privileges of the file owner (typically root). That means that *anything* from the user environment is potentially an attack vector. In this case it was as simple as environment variables. So the tables turn, and now the developer must *explicitly* guard against malicious injections rather than coding to a well-defined contract where parameters are explicit. Not to mention that the developer may not even be aware that someone will change the executable to SUID or just invoke the executable as a tool from another SUID executable (example: sudo).
turned off almost all the reporting features
But not all and you can't prevent MS from changing your shit with forced updates. Or are you using Enterprise?
Yes all. And you cannot prevent Apple from changing your shit when they update OS X. What makes you think that MS will use Windows Update to change settings? They have never done so before, and have not indicated that they reserve that right for the future.
I don't understand why people think this sort of thing doesn't happen. It has been *publicly disclosed* that this level of spying takes place. The NSA was caught red-handed putting spyware in the firmware of routers being sent overseas...why in the world wouldn't they partner with Microsoft to inject spying software into Windows?
It would be naïve to think that NSA do not try something like this. But what would Microsoft gain? They would risk their entire revenue, for what? Favors of the NSA? Microsoft - and any other vendor with business in US - will have to comply with lawful orders. Unfortunately, FISA decisions are not public. But Red Hat or any other vendors would have to comply with the same FISA orders.
That isn't the issue. The issue is YOU being able to share MY WiFi key because I was dumb enough to let a Windows 10 user on my WiFi network. This is akin to me giving you the keys to my house so you can housesit, and you getting a hundred copies cut and distributing them to a bunch of people you know.
So wrong.
If you *tell* someone your WiFi password *then* there's nothing stopping them from sharing it with whomever they want. So do not do that. Not if he brings OS X or Linux or Windows.
If you want to allow some friend onto your network but not allow him to share your network with others, then *you* tap in the password at his computer when it connects. On OS X or Linux or Windows. That what you would do today, and that's what you would do when your friends brings a Windows 10. On Windows 10 simply DO NOT CHECK the "share" checkbox. It is off by default. Your network will not be shared.
Nothing has changed. Neither your network nor your password will be shared with anyone. Your friend cannot go into settings and share the network after the fact - it has to be done when connecting.
But if *you* connect to some network which you would like to share with your friends, you can check the "share" checkbox. When you do that, your password will be stored encrypted in Microsofts servers. When one of your friends (if you share with - say - Facebook friends) is in range of that network, his Windows 10 computer can engage the network. The network will issue a challenge with must be hashed using the password as salt, and the hash returned. Modern password auth works like that to avoid sending passwords in cleartext. This means that the *actual* password hash is a one-time hash computed from the challenge.
The computation of the hash is performed on Microsofts servers, and your actual password is NEVER available on your friends computer - not even in encrypted form - only the challenge response hash. Your friends computer must obtain the response to the challenge from Microsofts servers - and when doing so it must prove that it belongs to a friend of yours.
Furthermore, Windows 10 which connects to a network in this way will *not* allow access to other devices on the network except for the internet gateway. I.e. it can only be used for Internet access - nor for local file or media sharing.
Even with disk cleanup removing redundancies in the winSXS folder, it can still swell to be over 12gb in size.
There are no redundancies in the WinSxS folder. That's actually the point of WinSxS: It is a "repository" of sorts where all OS files are stored and the actual files are merely hard links to the file in WinSxS. That way, even if a file is placed in multiple places, it is still only a single file.
To be able to *uninstall* updates, WinSxS does hold on to the "old" files. That way, if you roll an update back or uninstall a component, Windows will simply change the hard link or delete the linking file. If you do not want to be able to roll back to a previous state, you can always clean up by discarding the "old" service pack files by issuing the command "dism /online /cleanup-image /spsuperseded"
LINQ is the PHP for those who can't design proper data architecture and access layers.
I have a suspicion that you have no idea what LINQ is.
Sorry man, mysqli_real_escape_string_honest_guv_we_won't_change_this_again has been flagged for depreciation with no planned replacement.
It is deprecated in PHP 6.
But PHP 6 has been deprecated, so now it's back in. Until it's not.
So to summarize: as a user, you can sometimes write to EFI memory.
That's currently all there is to it. There's no rootkit, there's no malware, etc. Just this space where you can hide and survive an OS wipe and reinstall.
Yes - it is a vulnerability for which there is no exploit published (yet).
This vulnerability is serious, as it allows an attacker to permanently infect the Mac *firmware* and gain control each time the Mac is booted - even if you nuke and reinstall OS X.
You may try to dismiss this as "still needs another vulnerability". Another vulnerability or even a social engineering attack, evil maid attack will all suffice. This one can be used to take permanent, undetected residence on successfully exploited macs.
That's bad in my book
I am nervous as this feels like early 2008 all over again.
Don't be. In 2008 there was a real risk that banks would fall like dominoes. When talk started about a possible Greek default in the first round, the same concern was there: That a lot of European banks had so deep loans to Greece that a Greek default would cause the banks to start toppling and cause a widespread crisis in Europe.
This time, the other European states (notably Germany), ECB and IMF have largely taken over the "bad debt" from the banks. Which means that Central banks, ECB and IMF will have to write off some loans if Greece defaults, but banks and the financial system is largely insulated.
Last time, Greece used the threat of throwing Europe into a deep financial crisis as negotiation leverage. This time, that threat has been neutralized and that is why you see other European leaders standing more firm on Greece owning up to their situation.
Talk about WWII reparations is NOT owning up to the problems that created this crisis in the first place. Greece were about to be exposed as insolvent before entering the Euro. But getting into the Euro meant cheaper loans and could postpone the point where they ran out of money. So Greece at the time lied and cheated their way into the Euro: They "mistakenly" left out the state obligations for pensions as obligations (should have counted as long-term debt). They got in and got access to cheaper loans. But they did not mend the broken system, and here we are.
Greece must own up.
And that was new loans AT INSANE RATES.
Last time I've checked check dept per citizen numbers, Greek was roughly on the level of Germany.
But interest rates they are paying (and that mostly to German banks), oh my goodness:
Interest rates reflect the lenders perceived risk of not being able to retrieve the loan on time or at all.German citizens are vastly more productive than Greek citizens.
If I were to lend 10.000 euros to someone, I'd have a better chance of having that loan paid in full from a German citizen living and working in Germany than from a Greek citizen living and working in Greece. That does not mean that I would not lend to Greece, but it means that I would take a higher interest rate to compensate for the risk.
It is not a diabolic German plan to put Greece down. It's just economics.
Or someone who's discovered the recent 'innovation' of Nuget. That thing is a monstrosity.
Could you be a bit more specific about what it is that makes NuGet a monstrosity?
So this is just a sys-admin tool. Not a general purpose scripting language.
It is a general purpose scripting language.
An object-oriented general purpose scripting language with a number of features that makes system administration easier.
One example is DSC. It is a scripting language that can use the DSC *platform* to make sure that target systems are all configured the same way, albeit each with different parameters.
Another example is workflows. Wake me up when bash or python can start a script that can survive system restarts and pick up and continue from where it was when the system restarted, complete with state, variables etc.
Nah. In PowerShell:
iwr "http://server/path/to/file.zip" -outf "${env:TEMP}/file.zip"
You can try to make it look more verbose. But expect to be called out on it.
You can accomplish almost any task with fewer keystrokes in PowerShell compared to bash - and the resulting command will still be more readable.
But if I am going to learn something new, what advantages this powershell has that python does not? Cygwin + bash is cross platform enough for me to switch between ssh windows in linux boxes and my windows desktop.
Desired State Configuration (DSC) that FTFA was about, is definitely one such thing that PowerShell has that python has not. DSC is a *declarative* description of the configuration you want for a target system. You should think more in line of Chef or Puppet than Python. PowerShell DSC for Linux actually *uses* Python.
The idea is that you use PowerShell to define a data structure (much like a Ruby hash) that describes the configuration of the node. DSC will itself resolve dependencies. If you require a feature DSC will ensure that the feature is installed - much like a package manager - but it actually interacts with the package manager. What package managers do not do is to configure the products once they are installed. This could be connection strings, IP addresses, user accounts.
PowerShell DSC for Linux has "resources" for file system, user accounts, text file content, package managers (Yum, Apt, Zypper), scripts, daemons, ssh keys and more. You use those resources to describe how you want a system to look - like a Chef recipe. The resource description can be parameterized (it is just a PowerShell function and can take parameters like PS functions) so that the same resource description can be used for multiple targets with slightly different values.
Once applied, DSC will ensure that the target is set up so that it matches the target. From there on it can also report on drift (e.g. more users created, files deleted/changed etc) and can warn about it and automatically bring the node back to the desired state (undoing the drift).
Wordy is the key issue, look at your average unix app generally all the flags can use a short - or a long -- for the same function.
How about if the unix app allowed only the long form option names - but allowed them to be abbreviated as long as the abbreviation was unambigous? (That's what powershell does)
PS forget that 30+ years of unix shell to near perfection and rolled their own verbose and obtuse creation
That why we still code in assembler and don't use those modern touch screens. Oh wait... (lalalalalalalal! -- fingers in ears, eyes firmly closed)
They will not get bash to work well under windows. The problem is the brain-dead and overcomplicated NTFS permission system. There is no way to get that handled without just as over-complicated and brain-dead "special" tools.
Yes, there is no concept of SUID/setuid on Windows. So there's no sudo "happy go lucky".
1. What is awkward with string parsing? Is this shell aimed at _incompetent_ people?
No, PowerShell is aimed at admins who want *robust* scripts - both the ad-hoc ones they whip up as well as the ones they choose to save. String parsing is extremely brittle, and most bash shell scipters do it the insecure and brittle way because it is easier.
String parsing is often thrown off if presented with unusual characters in file names, if executed in locales where dates and numbers are both generated and parsed different, etc.
2. And that works how on Linux?
OMI is available on Linux. Read the FTFA
3. An IDE in a Shell? Is the syntax so bad that you need an IDE? Or is this another effect of being aimed at incompetents?
You're the incompetent one. There's is no "IDE in a shell". The ISE *is* the shell - much like if you did bash scripting from emacs. The difference is that the ISE will provide you with intellisense (automatic suggestions), help, syntax highlighting, snippets, multiple script panels, integrated source-level debugging (complete with breakpoints, variable inspection etc) and even a command "builder".
4. Aehm, know any mainstream modern shell that does _not_ have excellent documentation?
Most *nix shells have good documentation. PowerShell has good documentation as well. All of the cmdlets have syntax descriptions (automatically generated from metadata), description and multiple examples. In PowerShell even user-defined functions, cmdlets and script files can have the same level of documentation. Comment based help (look it up) makes it super easy to document scripts and functions. And the auto-generated syntax diagrams and parameter descriptions also work for your own script files.
5. Seriously? I found the command syntax exceptionally awkward and badly thought out. I am back to a cygwin console for most things.
PowerShells command syntax is extremely consistent. Cmdlets are *always* of the verb-noun form, and there are only about 40 or so standard "approved" verbs. Parsing of the command parameters is the responsibility of the *shell* not of the commands like in *nix shells. Hence, all commands follow the same convention with no strange outliers like e.g. dd. Parameter names are always "long" - but can be abbreviated as long as the abbreviation is unambigous.
Why is it that when I look at wikipedia , they show all the various counters more or less in agreement, except netapplications which vastly overcounts IE and undercounts Chrome, android and safari?
Maybe because Net Applications is the only counter that tries to correct for known skewed sampling. Net Applications uses CIA internet usage data (how much of the population in each country has access to the Internet) to estimate absolute numbers for each country based on the measures distribution and the "Internet" population number. Net Applications is perfectly honest and upfront about this.
The other counters just report whatever stats has been collected. They also are perfectly honest and upfront about this.
Both correcting and not correcting may leave errors. Be your own judge.
But there's a perfectly good explanation as to *why* the numbers seem not to agree: They do not even claim to illustrate the same thing. Net Applications tries to create a number for "true" global distribution (and risk errors), the others do not even claim to compute such a number. In theory you could take the numbers from, say statcounter, by country and extrapolate the absolute number per country, sum them up by browser and calculate a number similar to net app. Could be interesting to see.
Also, be aware that there is also great popential for skewed demographics between the counters, not to mention the fact that Net Applications tries to measure unique visitors (discarding repeat visitors within a month) while most of the others just report page impressions. If for instance users of Chrome are more active on the 'net than users of IE, chrome would have a bigger share of page impressions than they would of unique visitors. There is no "right" in this: It all depends on the question you ask: If the Q is "which browser is the most popular?" you would look at unique visitors. If the Q is "which browser is used the most?" you would look at page impressions.
Why is it that of all the various counters netapplications is the one most often quoted, even though they appear to be using a bad methodology.
Maybe because they use the *least bad* methodology. The others do not even *pretend* to estimate global usage. They may report what *they* see of usage globally, but none of them claim to know how many users there are in each contry.
Climbing Everest is stupid, irresponsible, dangerous, pointless task for people with severe mental problems like constantly needing approval from others or pathological levels of arrogance or constantly feeling inadequate. So I have to wonder how he even got that job at Google with the personality of an Everest climber.
He was privacy director at Google. Hello? Being away climbing mountains 11 months a year was a core qualification.
1) Are you saying that the signature does not cover the entire download, and that an attacker could supplement or exchange content of the download without invalidating the signature, and have the injected code execute when the user starts the app?
2) Sounds bad.
3) Sounds bad
4) That a signature-based AV engine is only effective when attacks have been reported, analysed and a has been signature developed is bloody obvious. All an AV engines is good for is herd immunity. Which is sorta ok, except that they are peddled as the most important security product *you* can use. Some AV engines more advanced than XProtect use heuristics (or se they claim) but I have to admit that I am *really* sceptical about the claims of the effectiveness.