Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:Very sad - but let's get legislation in place N (Score 1) 705

Sounds like someone's being reading the promotional material. I don't know what part of Australia you live in but I actually work in many Australian data centres and I *promise* you, I could get in without an AK-47. I have personally coat-tailed in to many of them, behind complete strangers, on more than one occasion. I make a game of trying to do just that, in fact - just to see if anyone ever stops me. In all the times I've done that, I recall once that the person in front of me, who I was coat-tailing, actually stopped me and asked me for my ID. Considering he was not even an employee of the datacentre but just a colo customer, I don't know what he could even have done, had I told him to get stuffed.

Many of them would be trivial to break in to, if I didn't care about leaving physical damage behind and the only ramification would be I'd be caught on film (which would hardly be a major issue for someone willing to think it through).

For all the talk about being extremely secure, many are basically if not completely (usually completely) unmanned after hours, many are in normal office buildings in and around the various CBDs and rely on little more than a swipe card preventing you selecting a specific floor from the lift and not having a hammer to break the invariably glass door past said lift (which may be tempered glass but it's still only a couple cm embedded into an aluminium frame, so bullet-proofing isn't going to help, here). There are a handful of higher tiered ones scattered around that do have (a single) security guard(s) after hours but I they're usually little more than a concierge.

As with all things in Australia, the vast majority of our datacentre physical security comes down to our national security policy of "it'll never happen, so why worry about it".

I have been in datacentres that house equipment belonging to a certain American company, that starts with "G" and ends with "oogle" and the only enhanced security they had was a yellow mesh around their racks, made out of the same stuff that fails to protect the doors and windows of residential houses from 12 years olds on a daily basis.

I've been in the supposedly "most secure, tier 3" commercial datacentre in the country and seen the perimeter fence and main access doors propped open by reels of cabling, because electricians doing onsite work didn't want to have to be buzzed in, constantly, while collecting stuff from their vans. I've even had an electrician who was testing onsite UPS hold doors to secure areas open for me, without asking me who I was or if I had access to them (without me even asking him to). Security in Australian datacentres is not quite where it should be.

Comment Re:And how much do they pay for slashvertisements? (Score 1) 434

I doubt either Apple or Microsoft either paid for, or were even aware of this Slashdot "article". I'd say it's infinitely more likely Slashdot simply know starting a holy war people Apple and Microsoft fans (or Microsoft fans and anti-Microsoft or Apple fans and anyone) just guarantees clicks. Look at the articles on the main page - this one far and away has the most comments.

This is about ad revenue through clicks, from the Zealots that are guaranteed to comment below - not direct paid product endorsement.

Comment Re:For the love of... (Score 2, Insightful) 56

When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage? Even 'ancient' Linuxs only add the first user to sudoers so that they have to explicitly invoke rootly powers.

Unlike Linux, Windows uses proper security tokens. Each process has it's own token governing what it can do to which resources. On Linux the "token" is - rather naively - a user id.

When you log on to Windows - since Vista - with an account with administrative rights, thee token that is created for the shell process is 1) stripped of all administrative rights and 2) given an integrity level of "normal". Integrity levels are also part of the token.

What it means is that *even when you log on as an administrator* you do not possess any administrative or god-like rights. You are a standard user.

When you invoke a program that has a manifest which states that it requires some form of administrative rights, Windows will prompt you for "elevated" privileges. Only when you accept to use your administrative privileges will the process be started with a token with higher than standard user rights.

It really is a much more elegant solution than the stupid effective user in Linux, where the description of a process rights is strongly tied to a user: There must exist a user with the specific sets of rights you want the process to have. Not so on Windows: Any process can have it's own token with fewer or more rights/privileges.

You can turn off UAC (don't!), which is why Microsoft must write the disclaimer *If the current user is logged on with administrative user rights*. If you turn off UAC and log in with an administrative account - then you run all processes with full permissions/privileges.

When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage?

They did fix it. You are just ignorant.

How many of these problems could be mitigated if this were not MicroSoft's default approach?

The answer is 92% - and it is mitigated by default.

Comment Re:Minor upgrade if you only look skin deep. (Score 1) 321

Hyper-V on Windows 7 is a very different beast, as it was version 2. It was by no means a seriously powerful tool. Hyper-V 3 is a different story. It's significantly more powerful and feature rich. Which is why, and I'll help you with the comprehension on this one, I said " having a very powerful Hypervisor built in". See those key words, there, "champ"?

Comment Re:One client has fallen for it four times (Score 1) 148

Ha! She was probably very pretty about 30 years ago - and her boss is also a later-middle aged woman, so I think that's... improbable. So far as I can tell, her job description is 100% to shield her boss from having to deal with anyone (she's a P.A.). And she's very good at it - if you even meander slightly near her boss's door, she'll just about spear tackle you to stop you going in there and she's no different when it comes to phones or other forms of shielding her boss from annoyances. But when it comes to anything else, I think she really just makes busy work to keep herself amused, as her boss spends about 50% of the year out of the country, anyway.

Comment One client has fallen for it four times (Score 4, Interesting) 148

I know someone who personally accounts for 4 of those installations. On the same computer. Because she's fallen for the same frikkin scam four times. Every time I ask her "why did you open an email claiming to be from the IRS, when we don't have an IRS in Australia", she tells me "because it sounded real". You should see the grammar in these scam emails, too: they're written like "please effective the transactionments with the rapid or we can has your cheeseburgers". Yet she's still fallen for it. Four. Times.

Fortunately, I back that site up effectively.

Comment Re:Meanwhile, in Canada (Score 4, Interesting) 155

No, Cortana is not available in Canada because Microsoft enjoys giving a massive middle finger to anyone who's not an American. Trust me. I have a Windows Phone and a Surface Pro 3. I couldn't be more in the "Microsoft Ecosystem" if I tried. But I'm not an American - I'm an Australian (and English is the language here). Despite Cortana being the selling point for WPh for years, they still don't have support for it in Australia (they recently offered "alpha" support on the phone only and it's missing most features) and you can't get Cortana on Windows 10, either. I routinely get emails from Microsoft about sales or deals in the "Windows Store" that only apply to Americans (so I can't get the discounts or free offers), despite the fact they can clearly see from the information they have on me that I am not an American. It's just one, never ending middle finger from them, and it's the #1 reason I doubt my next phone will be Windows based.

Maybe someone at Microsoft should look around the WPh sales and realise that the vast majority of Windows Phones in the world are actually not in the USA and start offering support to the people who actually did buy their products??

Considering Cortana is the #1 selling point - you think they'd put some effort into making it work for the 95.71% of the planet who doesn't live in America.

Comment Minor upgrade if you only look skin deep. (Score 1, Insightful) 321

*Windows 8* was a significant upgrade over Windows 7 - and Windows 10 more so. However, if you only care about start menus and icons, then, no, there's nothing to see here.

I don't recall, however, Windows 7 having native NIC teaming built in, including on dissimilar connection types (i.e. natively team wifi and NIC). I don't recall Windows 7 having a very powerful Hypervisor built in, natively. I don't recall Windows 7 having SMB3. I don't recall Windows 7 having native support for software defined storage and software defined networks. I don't recall Windows 7 supported RFS. The list goes on, and on.

But no, clearly Windows 10 is a very small upgrade over Windows 7.... if the only thing you ever look at is the f*cking start menu. I thought this was supposed to be a tech site? Where people discussed the real technology in things - not just how shiny they are? Did I wind up a Daring Fireball, by mistake??

Comment Re:10.11 should be immune anyway (Score 1) 127

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)

Comment Re:10.11 should be immune anyway (Score 2) 127

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!

Comment Re:Privlege escalation exploit change looks like t (Score 1) 127

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.

Comment Re:Better link (Score 4, Insightful) 127

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?

Comment Re:Better link (Score 3, Insightful) 127

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).

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Working...