Exploits Emerge For Linux Privilege Escalation Flaw

Broken on Android too by StayFrosty · 2012-01-25 10:50 · Score: 1, Interesting

Awesome that this will lead to easier root access on Android devices.
On the flip side I'm sure Android vendors won't get around to patching this for a while and our devices will be vulnerable.

Now, off to patch my Linux boxen.

--
"Frequently wrong, never in doubt."

Re:Broken on Android too by toadlife · 2012-01-25 11:10 · Score: 2

this will lead to easier root access on Android devices
When I saw the headline that's exactly what popped into my head; "one-click" root tools for various Android devices that don't currently have any.

--
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Re:Broken on Android too by jd · 2012-01-25 11:53 · Score: 2

Pinky, are you thinking what I'm thinking?

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:Broken on Android too by Abreu · 2012-01-25 12:08 · Score: 5, Funny

Wuh, I think so, Brain, but if we didn't have ears, we'd look like weasels

--
No sig for the moment.
Re:Broken on Android too by JAlexoi · 2012-01-25 13:28 · Score: 1

Except that only version 4.0 is vulnerable. And only GNex and Nexus S have that version deployed by.... Google! So I see an update pretty soon.
Re:Broken on Android too by bfree · 2012-01-25 13:32 · Score: 3, Informative

Really? This bug was only present in kernel releases 2.6.39 and newer. Do any Android devices use kernel's based on a Linux this current? A quick search says Android 2.3. used 2.6.35 and 3.0 used 2.6.36 so the number of devices this might possibly help you root looks miniscule.

--
Never underestimate the dark side of the Source
Re:Broken on Android too by NeoMorphy · 2012-01-25 13:53 · Score: 5, Funny

Really? This bug was only present in kernel releases 2.6.39 and newer. Do any Android devices use kernel's based on a Linux this current? A quick search says Android 2.3. used 2.6.35 and 3.0 used 2.6.36 so the number of devices this might possibly help you root looks miniscule.
I am replying with my new Asus Transformer Prime, which is running ICS(Android version 4.03), kernel is 2.6.39.4.
I'm thinking this bug is God's way of saying "You are loved. Now go forth and exploit your tablet!"
Re:Broken on Android too by slack_justyb · 2012-01-25 16:57 · Score: 3, Informative

Someone has already beaten every one else to the punch.

However, you need Ice Cream Sandwich and you will need access to a disassembler. Also, you cannot use this exploit for "one-click" root access as the only program that is in the Android stack that runs setuid root, is run-as. That command is statically linked so you will still need adb access so that you can disassemble the program to find it's exit call.

So there is still a fair amount of work left to be done to make this an exploit that can be used in the "wild" for Android devices. However, as a fair note. A little crowd sourcing to compile a list of offsets for different devices could greatly speed up the process. I'm actually curious if Google will patch this in there kernel.
Re:Broken on Android too by hairyfeet · 2012-01-26 02:22 · Score: 1

If its from the same ones that make clitter I probably shouldn't ask exactly WHERE that wand is located,should I?

--
ACs don't waste your time replying, your posts are never seen by me.
Re:Broken on Android too by crutchy · 2012-01-28 11:49 · Score: 1

do not ignore my veins!
Re:Broken on Android too by crutchy · 2012-01-28 11:55 · Score: 1

our devices will be vulnerable
only if you're dumb enough to install apps like "HotNakdChyX" from "WeRHaXorZ" that require every permission possible
Re:Broken on Android too by StayFrosty · 2012-01-28 12:09 · Score: 2

If your browser/flash player/some other legit app has a zero day that allows the execution or arbitrary code you are just as screwed as if you install a malicious app.

--
"Frequently wrong, never in doubt."
Re:Broken on Android too by crutchy · 2012-01-28 12:51 · Score: 1

If you're using flash then you're already dumb by default, along with anyone who enables Java in their browser.

Javascript could be a possible vector, but seems like a bit of a long shot.

I think the majority of malware development on Andriod is probably focused on the ignorance of users just installing apps that require ridiculous permissions. If the user wants an app/game enough, they are likely to accept whatever permission it says it needs regardless of whether it actually needs them or not.

Security of Android would be greatly improved if the Market installation front-end made it clearer about the consequences of certain permissions and helping users understand the likelihood of any given app "requiring" a certain permission or whether a permission is unnecessary for the type of app such that there is a possibility of that app having a darker purpose. Maybe highlighting permissions with higher security risks that aren't usually really needed by apps in the same category would be a positive step.

i don't think the Android situation is any worse than Windows (or even Linux) because in Windows, if the installation program requires admin privileges you have to allow it or you can't install the program, and if you allow it the program can pwn the entire computer. At least Android breaks down privileges into specific functions. Unfortunately the consequence of this is increased difficulty for users knowing what the various permissions actually mean.
Re:Broken on Android too by crutchy · 2012-01-28 12:57 · Score: 1

an even better security measure would be to allow the user to prevent access to a certain permission, while still allowing the app to think it has that permission (call it "permission spoofing"). that way if the app doesn't really need the permission, it will work just fine without it. worst case is the app stops working and you have to restart (or uninstall) it.
Re:Broken on Android too by StayFrosty · 2012-01-29 05:14 · Score: 1

You are almost right. Sadly, some of us need flash and java to do our jobs. F*** You Cisco!

--
"Frequently wrong, never in doubt."
Re:Broken on Android too by sayno2quat · 2012-01-30 08:26 · Score: 1

an even better security measure would be to allow the user to prevent access to a certain permission, while still allowing the app to think it has that permission (call it "permission spoofing"). that way if the app doesn't really need the permission, it will work just fine without it. worst case is the app stops working and you have to restart (or uninstall) it.
You can do this with many custom roms by default, or with the Permissions Denied app, provided you have at least root on your stock rom. I disable permissions on some apps, and generally find that they force close fairly soon, if not instantly, after starting the app.

--
Sure I sold you robot insurance. But you were attacked by a cyborg. Not covered.

Hrrm by Anonymous Coward · 2012-01-25 10:51 · Score: 5, Insightful

If someone is in a position to run a local exploit, aren't you pretty much fucked anyways?

Re:Hrrm by JimCanuck · 2012-01-25 10:56 · Score: 3, Insightful

Yes that you are.
Re:Hrrm by MichaelSmith · 2012-01-25 10:56 · Score: 4, Insightful

Web servers are vulnerable because they run server side code, often uploaded with vulnerable content management systems, etc.

--
http://michaelsmith.id.au
Re:Hrrm by EvanED · 2012-01-25 11:03 · Score: 2

Right, because no organization would give their employees user access to a machine but not root.
Re:Hrrm by Barbara,+not+Barbie · 2012-01-25 11:16 · Score: 2, Insightful

Of course. The best local exploit is a screwdriver and a spare moment or two.
Some quick contrarian rules:
Rule #1: There is no such thing as 100% secure. Even 100% bug-free cannot be considered 100% secure. It may work according to the design, and the design can be 100% correct today, but today is not tomorrow.
Rule #2: The more complicated layers of security you add, the more security holes you add. For those into car analogies, security always ends up being bolted on, like bondo dent filler, because you can't anticipate every future accident scenario. Anyone who claims otherwise is either a charlatan, a snake-oil salesman, a liar, or just plain deluded. Those who claim "you can't add security later" are liars. Those who use unix as an example don't know history - unix originally had zero security.
Rule #3: All security is ultimately "security through obscurity." If you believe open is more secure, please post your account info, including cc numbers, banking info, user names and passwords, to help make them "more secure". I'd say just email them to me, but "more eyes" and all that :-)

--
Let's call it what it is, Anti-Social Media.
Re:Hrrm by Anonymous Coward · 2012-01-25 11:41 · Score: 5, Informative

I was with you up until Rule #3 which is nonsense.
Re:Hrrm by Mad+Merlin · 2012-01-25 11:47 · Score: 4, Interesting

Rule #1: There is no such thing as 100% secure. Even 100% bug-free cannot be considered 100% secure.
There's also no such thing as 100% bug-free.

Rule #3: All security is ultimately "security through obscurity."
While in the strictest sense, this may not be untrue, to phrase it that way is extremely dishonest. An encryption algorithm that relies on the secrecy of the algorithm is totally worthless (security by obscurity), whereas an encryption algorithm that relies on the secrecy of the keys used for encryption is quite useful (not security by obscurity in the normal sense).
In fact, if you want to be pedantic about it, the relevant definition for obscure is...
not readily understood or clearly expressed; also : mysterious [1]
Which is about understanding and not so much about knowledge. I may understand that I need a username and password to log into your system, just because I don't know what the username or password is doesn't make it security by obscurity. In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.
If you're going to go ahead and say that all security is "security through obscurity", then you may as well make the next logical step of not implementing any of it.
[1] http://www.merriam-webster.com/dictionary/obscure

--
Game! - Where the stick is mightier than the sword!
Re:Hrrm by Carnildo · 2012-01-25 13:30 · Score: 2

Have you vetted crt1.o for correctness?

--
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Re:Hrrm by Mad+Merlin · 2012-01-25 14:14 · Score: 1

Your program didn't do what it was asked to. Why didn't it return an error code?

--
Game! - Where the stick is mightier than the sword!
Re:Hrrm by Mad+Merlin · 2012-01-25 14:21 · Score: 1

Your "contrary example" actually proves my point.

In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.
Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured.
You contradict yourself. If you didn't need a key why would you go get one made? Furthermore, what ceases to be obscured through the process of taking your knowledge of the key's teeth and having a replica made? (Hint: nothing)

--
Game! - Where the stick is mightier than the sword!
Re:Hrrm by NeoMorphy · 2012-01-25 14:31 · Score: 1

There's also no such thing as 100% bug-free.
What kind of attitude is that? /bin/true on Solaris looks bug free to me.
Re:Hrrm by Barbara,+not+Barbie · 2012-01-25 14:39 · Score: 1

The fact is that keys only work when the pin lengths are not known. You can also open a lock without the key (or any key) - just search for MIT Guide to Lock Picking.

--
Let's call it what it is, Anti-Social Media.
Re:Hrrm by Myria · 2012-01-25 15:11 · Score: 1

Have you vetted crt1.o for correctness?
Fine.
mov eax, 60
xor ebx, ebx
int 0x80

--
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Re:Hrrm by LingNoi · 2012-01-25 15:39 · Score: 1

I could see a few ways to do it..
- Linux games are becoming more popular
- A poorly coded script on a webserver that lets you upload and execute a file
Re:Hrrm by alreaud · 2012-01-25 15:43 · Score: 1

... (and biometric is the biggest joke of all).
Explain please. I worked on a very secure military installation east of Colorado Springs. You had your retina scanned, locked in a bomb-proof slightly bigger than coffin-sized box, as you keyed in a pin and were weighed. This while being watched by the biggest grunts I have seen in my life with M16's. If the biometrics didn't match the pin, the grunts would escort you out of the box. The sign on the wall in big bold letters says "USE OF DEADLY FORCE AUTHORIZED".

Joke? That was the only for real security I have seen in my life. Any spying done on that base is an inside job or a contractor. So in the end, your last statement is true, but #3 is still only partially correct. The best kept secrets are those that can be hidden in plain view. Obscurity sometimes is a hole that invites a peek. An example is hidden SSIDs.
Re:Hrrm by anonymov · 2012-01-25 15:45 · Score: 3, Interesting

"The fact is private encryption keys only work when P and Q are not known. You can also decrypt the cyphertext without the key - just search for $5 wrench"
You're mistaking "secret", which is necessary part of every encryption scheme, with "obscurity", which is useful only in very specific circumstances.
Following your analogy, security by obscurity is making key duplication method secret and hiding the lock's inner working. Good security, on the other hand, is when you can't duplicate the key unless you snatch it from the owner and can't pick the lock even if you know how it's built.
Security by obscurity is useful only as preliminary defense line to stall an attacker until he gathers enough information about your systems to begin targeted attack.
Re:Hrrm by LingNoi · 2012-01-25 16:18 · Score: 1

and if you compile it with a buggy compiler?
Re:Hrrm by Anonymous Coward · 2012-01-25 16:33 · Score: 1

The sign should have said "WE APOLOGIZE FOR THE INCONVENIENCE"
or just "DON'T PANIC"
Re:Hrrm by xaoslaad · 2012-01-25 16:55 · Score: 1

Attacks come from inside too. Disgruntled user, or even just a dev or curious individual who read an article and decided to go try it. Shell and bastion servers are a reality for some.
Re:Hrrm by thedrunkensailor · 2012-01-25 16:58 · Score: 1

echo 'hello world'

--
i support the right to offend.
Re:Hrrm by drolli · 2012-01-25 18:33 · Score: 1

so i gather we just forget about any access control and everybody is root?
Re:Hrrm by Dal+Platinum · 2012-01-25 21:03 · Score: 2

You had your retina locked in a box? Holy shit.
Re:Hrrm by evilviper · 2012-01-25 21:42 · Score: 2

If someone is in a position to run a local exploit, aren't you pretty much fucked anyways?
No. "Multiuser system" indicates users are secure from one another. Linux is not ms-dos. I'm sure vmware would like you to believe otherwise.
Network services use multiuser system access controls to good effect. Bind, ntp, etc., will chroot themselves into a nearly empty dir, and then drop privledges. This means an exploit in, say, bind results in attackers only getting a non-privledged account access on the target system. Since those chroot'd users can't access /proc, or any other suid programs, network services are still pretty safe.
There are services out there which provide shell accounts

--
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Re:Hrrm by CSMoran · 2012-01-26 01:04 · Score: 1

It runs fine in bash...

--
Every end has half a stick.
Re:Hrrm by hairyfeet · 2012-01-26 02:42 · Score: 1

And I can just pop on over to newegg and buy that system right? no? Dude i don't think comparing some multimillion dollar MilSpec retina scanner to what the average person can get, which can be fooled by a gummi bear on the print and whose cameras can't "see' black people is really a fair comparison, do you? to use a /. car analogy that would be like saying "car alarms don't deter car thieves" and you say "Well the last time someone sat an alarm off on base they was hog tied by 4 MPs before they could say "ooops" yee haw'. since the average person doesn't have MPs with hog tying skills standing within earshot of the alarm on their 03 honda i kinda doubt that's a fair comparison. it was pretty obvious reading Barbra's post she was talking about what the average person gets, NOT what they have protecting the bombs at your average missile base.

--
ACs don't waste your time replying, your posts are never seen by me.
Re:Hrrm by hairyfeet · 2012-01-26 02:54 · Score: 1

And if you lock a machine in a safe its REALLY secure but not very useful ;-) The problem with security is its ALWAYS a balancing act between well secured and PITA for the person that actually needs to get their work done. I've seen both Linux with tough SELinux policies and Windows with tough GPOs that were pretty damned secure but if you had to use the damned things more than a few minutes at a time you'd want to pull your hair out.
In the end all you can do is weigh the pros and cons and make the best setup you can without being such a BOFH that you are afraid the secretaries will piss in your coffee. Because at the end of the day a computer is supposed to help the user do some work better/faster/cleaner and if its such a royal PITA that they'd rather use a pencil and paper than deal with the stupid thing there really isn't any point in having it, is there?

--
ACs don't waste your time replying, your posts are never seen by me.
Re:Hrrm by Barbara,+not+Barbie · 2012-01-27 10:14 · Score: 1

As you yourself admit in your closing remark:

Security by obscurity is useful only as preliminary defense line to stall an attacker until he gathers enough information about your systems to begin targeted attack.

... once I know enough about your system, you have a problem. If I know, for example, the hashing algorithm, I can begin a slow attack using rainbow tables targeting that hash size/characteristics, going from the most likely to the least likely characters. I don't even need to come up with YOUR password - just something that hashes to the same value.
If, on the other hand, you don't know what hash algorithm I'm using, or even what the characteristics of the passphrase are. For example, it may have to be exactly 12 characters, no more, no less, and x number of failures instead directs you to a honeypot, so you don't even know you didn't break in - keeping the knowledge that you failed to break in from you is great "security through obscurity" because it's proactive, and lets the target gather information to attack the attacker.
It's a lot better security than letting you know you failed to guess the passphrase, but it depends on obscurity - you cannot know that such a system is in place or it won't work.

--
Let's call it what it is, Anti-Social Media.
Re:Hrrm by Barbara,+not+Barbie · 2012-01-27 10:46 · Score: 1

Rule #3: All security is ultimately "security through obscurity."

I was contemplating giving a reasoned argument as to why this is wrong, but really can't be bothered when you're so clearly a moron who parrots out whatever internet meme happens to have lodged in your pinheaded mind this week. If you think all security is basically useless, do the world a favor and run everything as root while having no password set on your systems at all. There are plenty of kind folks out there who will help you learn just how amazingly wrong you are.

Silly me, thinking people can actually read ... where did I ever say that passwords aren't needed? Also, I'm not parroting an internet meme - I'm challenging it, because it's led to a fake sense of security. If you think that passwords are sufficient to secure everything, then you must believe that 2-factor identification is a dumb idea or overkill.

--
Let's call it what it is, Anti-Social Media.
Re:Hrrm by crutchy · 2012-01-28 12:32 · Score: 1

i think his key point was "The best kept secrets are those that can be hidden in plain view", which is true (if a rather obvious oxymoron)

the hard (impossible?) part is actually being able to hide something in plain view

the best that sysadmins can achieve in their time and budget is probably a mixture of conventional authentication with a bit of "security by obscurity", as the aim of many security specialists isn't to make a system totally secure but to simply make it more secure than it was before so as to reduce the likelihood of it being pwned by the majority of script kiddies and botnets. "security by obscurity" isn't really a bad thing, its just bad on its own. When combined with other security measures it can add a little bit to the effort required by any potential hacker.

banks often pay hackers to find security exploits for them as the old saying goes "better the devil you know", so if you want the best (tested) security, maybe hire a team from DefCon

Don't worry by spidercoz · 2012-01-25 10:59 · Score: 1

It'll be fixed tomorrow

--
"I disapprove of what you say, but I will defend to the death your right to say it." - Evelyn Beatrice Hall, re Voltaire

Re:Don't worry by Clarious · 2012-01-25 11:02 · Score: 1

In fact you can even fix it yourself while waiting for a patch with systemtap: http://www.outflux.net/blog/archives/2012/01/22/fixing-vulnerabilities-with-systemtap/

Re:Local exploit? by Lumpio- · 2012-01-25 11:12 · Score: 5, Informative

A weak SSH user account/PHP script/whatever + local privilege escalation = instant remote root

Re:Local exploit? by Anonymous Coward · 2012-01-25 11:13 · Score: 1

a) Someone just has to has a non-privileged (I.e. non-root) account, not local console access.
b) Changing run-level requires privileged access, that's why not.

All of the machines I manage are O.K: we haven't installed anything newer than 2.6.38 yet anyway.

Re:Local exploit? by gl4ss · 2012-01-25 11:15 · Score: 1

so someone has to be sitting in front of the boxen to exploit the exploit, why not just init 1? Serious question :)

"local" in this context usually means having a shell on the target machine - or similar way to upload and execute what you wish( and escalating privileges means that you escalate from "normal user who can't do shit" to something else, in this case root).

--
world was created 5 seconds before this post as it is.

Link to more info by milbournosphere · 2012-01-25 11:15 · Score: 5, Informative

It's a geekier breakdown, but is quite informative.

http://blog.zx2c4.com/749

Gets into the memory specifics of the bug. I found it to be far better than the actual article.

Re:Link to more info by c++0xFF · 2012-01-25 12:03 · Score: 1

Thank you! I was browsing through Linus's patch and couldn't make heads or tails of it.
That and I couldn't help noticing that he got rid of a bunch of goto statements while he was at it. At least these gotos were actually used for error handling...

Re:Local exploit? by guabah · 2012-01-25 11:23 · Score: 2

Asumming that by local they mean shell access, init 1 would disconnect you from ssh.

Re:Local exploit? by present_arms · 2012-01-25 11:24 · Score: 2

Fair enough, I guess I learn something new every day :)

--
http://chimpbox.us

Re:iOS now has more marketshare than Android by tqk · 2012-01-25 11:34 · Score: 5, Funny

Pardon me, but I'm going to go watch Firefly now, as it appears none of you make any sense. Bye.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Debian (mostly) not affected by Trogre · 2012-01-25 11:43 · Score: 5, Informative

Since this bug was introduced in Linux 2.6.39 Debian Stable (squeeze, Linux 2.6.32) is not affected. Unstable(sid, Linux 3.1) has already been patched, though Testing (wheezy) is still vulnerable.

More information here

--
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife

Re:Debian (mostly) not affected by IpalindromeI · 2012-01-25 13:44 · Score: 1

I've been looking around but haven't found any information on when the fix might migrate into Testing. Any idea?

--

--
Promoting critical thinking since 1994.

Re:We all call for it! UAC for Linux! by Culture20 · 2012-01-25 11:51 · Score: 1

sudo and selinux/apparmor. done.

Re:Local exploit? by BasilBrush · 2012-01-25 12:17 · Score: 5, Funny

so someone has to be sitting in front of the boxen to exploit the exploit, why not just init 1?

Or they could use axen to destroy the boxen. Or set some foxen on them to tear them to pieces. Or they could fill the boxen with melted waxen. Or bury them in faxen. This exploit is usable by people of both sexen, so long as they pay their taxen.

Simple explanation by Chemisor · 2012-01-25 12:49 · Score: 5, Informative

There is /proc/pid/mem, a pseudofile referring to the memory of process pid. It has 0600 permissions so you can't write to the memory of other users' processes. The bug occurs when you exec an suid executable and the kernel does not change open fds for /proc/pid/mem. This way, you can open mem, dup it to stderr, and exec su with a garbage parameter. su will duly print an error, quoting the offending parameter, writing to its process memory. With a properly selected shellcode you can get root.

First thought... by scot4875 · 2012-01-25 13:18 · Score: 1, Troll

My first thought is that this is a perfect example of why Linux fanbois should pay more attention to the speck of dust in their eye than the logs stuck in Windows' and OSX's eyes.

Err, at least I think that's how the saying goes.

--Jeremy

--
Jesus was a liberal

Re:First thought... by LingNoi · 2012-01-25 16:23 · Score: 2

Look everyone, yet another OS war on linux exploit news, how original!

Re:/proc/pid/mem is an interface for reading and . by LordThyGod · 2012-01-25 13:30 · Score: 1

It only seems that way to the miserably uninformed. Relax. Smoke something.

Beware of ALL blanket statements ;-) by Zero__Kelvin · 2012-01-25 13:32 · Score: 4, Insightful

All security is ultimately "security through obscurity."

"I was with you up until Rule #3 which is nonsense."

Really? Try proving it's "nonsense". .

You either don't know what the word all means, or you don't know what the term security through obscurity means.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun

Re:Beware of ALL blanket statements ;-) by Provocateur · 2012-01-26 05:58 · Score: 1

You either don't know what the word all means, or you don't know what the term security through obscurity means.
It could be worse. He might not know about or, either.

--
WARNING: Smartphones have side effects--most of them undocumented.
Re:Beware of ALL blanket statements ;-) by Zero__Kelvin · 2012-01-26 06:42 · Score: 1

... or she ;-)
(Barbara is presumably a woman's name)

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun

Proof you are 100% wrong per your request by Zero__Kelvin · 2012-01-25 13:37 · Score: 5, Insightful

Again, you don't know what security through obscurity means. If the access to the code or other design that implements the security breaks it, then that is security through obscurity. All security relies on a secret known by one party, but unknown to others. This has absolutely nothing to do with security by obscurity.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun

Re:Proof you are 100% wrong per your request by Zero__Kelvin · 2012-01-25 15:16 · Score: 4, Insightful

Do you have a problem reading and understanding the English language? While I appreciate your attempts to credit the definition as my own, it has been an accepted term in security circles for a long time, and I am not the one who came up with it. Nobody worth their salt ever said that 100% security can be achieved, and you are not saying anything that isn't obvious to even a security neophyte like yourself. What is known is that security through obscurity is not an effective method of achieving security, even in deference to the fact that nobody will ever achieve 100% security.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Re:Proof you are 100% wrong per your request by AsmCoder8088 · 2012-01-25 15:51 · Score: 1

Earlier you made the following statement:

Rule #3: All security is ultimately "security through obscurity."
That is what is under debate. Is it true that all security is "security through obscurity"? There is a difference between understanding how an encryption algorithm works (obscuring an algorithm), and knowing a particular key to decrypt ciphertext using that same algorithm (obscuring an input to that algorithm).
For instance, it is possible to understand how the Diffie-Hellman algorithm works works -- meaning it is not obscure -- and yet still be unable to decipher the contents of a message encrypted via that algorithm. In this example, as in many others, the workings of an encryption algorithm need not be obscure in order to be considered secure.
In the sense that algorithms rely on their inputs, such as private keys, to be kept hidden (obscure), you would be correct. But since the phrase "security through obscurity" typically refers to the algorithm, and not its inputs, it would be misleading to claim that all security is "security through obscurity".
Re:Proof you are 100% wrong per your request by TaliesinWI · 2012-01-26 03:20 · Score: 1

Do you have a problem reading and understanding the English language? While I appreciate your attempts to credit the definition as my own, it has been an accepted term in security circles for a long time, and I am not the one who came up with it. Nobody worth their salt ever said that 100% security can be achieved, and you are not saying anything that isn't obvious to even a security neophyte like yourself. What is known is that security through obscurity is not an effective method of achieving security, even in deference to the fact that nobody will ever achieve 100% security.
It's a very accepted term, but you're not using the accepted definition. You're equating "obscure" with "secret". If I look at a security algorithm and by doing so enables me to break into whatever it's protecting, that's security through obscurity. If I look at one but still something like keys or passwords, that is NOT security through obscurity. Yes the keys or passwords are "obscure" but they _have_ to be, and that's not what people mean when they use that word.
Re:Proof you are 100% wrong per your request by Zero__Kelvin · 2012-01-26 04:02 · Score: 1

You responded to the wrong post, my friend. You are preaching to the choir. You want to follow up on a post from Barbie. That being said, as someone else already pointed out, obscure is not a synonym for secret, so you got that part wrong. A password or key is secret, not obscure.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Re:Proof you are 100% wrong per your request by TaliesinWI · 2012-01-26 04:38 · Score: 1

Yeah, I misquoted. Sorry about that. And I was telling Barbie that the mistake IS considering secret and obscure to be the same, but they're not.
Re:Proof you are 100% wrong per your request by Zero__Kelvin · 2012-01-26 06:40 · Score: 1

"Yes the keys or passwords are "obscure" ...

" And I was telling Barbie that the mistake IS considering secret and obscure to be the same, but they're not."
Just a point of clarification: you quoted obscure, but it ultimately leaves the impression that you could use the terms interchangeably, and feeds the confusion a bit.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Re:Proof you are 100% wrong per your request by Barbara,+not+Barbie · 2012-01-27 10:04 · Score: 1

Yes the keys or passwords are "obscure" but they _have_ to be, and that's not what people mean when they use that word.

The industry attempt to re-define "obscurity" is stupid, because it hides a few simple facts For one thing, how many people have secret passwords that are actually secret, in that they are obscure, rather than something personal, like the name of their pet, their birthday, or their kid?
Passwords are a classic example of the failure of "security through obscurity" - look under your co-workers keyboards for the post-its as just one example. Another is broken hashing algorithms, or attacks using rainbow tables, where, as long as you know the hashing algorithm, you can mount a much more effective attack.
ALL security needs something to be obscured - hidden - to be successful. The more you hide, the better.
If you still don't "get it", think of DDoS attacks - the only thing an attacker needs to know is what service you're trying to access. They don't need your password, your user name, just the "doorway" - and their DDoS is like sticking crazy glue in the lock to that door. If you can't use it when you want to, how is that "secure"? It's one reason to change the default url for admin logins in CMS systems (while leaving a bogus one that looks like the original. In larger systems, you'd also use a separate, unknown, IP).

--
Let's call it what it is, Anti-Social Media.
Re:Proof you are 100% wrong per your request by crutchy · 2012-01-28 15:03 · Score: 1

a security measure that presents a password prompt for authentication is a security measure that doesn't fit into the "security by obscurity" definition because the security measure itself is obvious. if on the other hand all you needed to know was a non-advertised URL (say) to get into the system, it would be considered "security by obscurity" because the system is still technically insecure

that you don't have the password to access a system doesn't make a password authentication security measure "obscure". there's nothing really obscure about it even in the normal definition (the word has multiple definitions, but one of them is (2) "not readily understood or clearly expressed" according to http://www.merriam-webster.com/dictionary/obscure

that you don't agree with the industry definition of "security by obscurity" is irrelevant, except that your apparent lack of understanding of it implies you don't work in the industry

Re:Local exploit? by Zero__Kelvin · 2012-01-25 13:41 · Score: 1

They don't have to be in front of the box, but even if they are the bootloader and BIOS might be locked down and they might have only non-privileged access to the OS.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun

Turtles all the way down by tepples · 2012-01-25 15:19 · Score: 3, Insightful

Have you vetted your x86 CPU vendor's microcode for correctness? How far down do the proverbial turtles go?

Re:Turtles all the way down by indeterminator · 2012-01-25 22:13 · Score: 2

Here are the missing steps:
Have you vetted the universe for correctness?
Have you vetted your brain for correctness?

Reboot into single-user mode by tepples · 2012-01-25 15:28 · Score: 1

I think present_arms's point is that local console access involves access to the big red switch and the bootloader, which on a PC-type system can be used to gain root by booting into single-user mode.

Re:Reboot into single-user mode by buchanmilne · 2012-01-25 18:48 · Score: 1

I think present_arms's point is that local console access involves access to the big red switch
'Local access' typically means that you have means to start processes as non-root, but does not require that you are near the physical hardware. Physical access means you are near enough to access the 'big red switch'. Privilege escalation vulnerabilities typically allow you to get from 'local access' to 'local privileged access'. Combined with a remote vulnerability (which allows you to get from 'can't start and control processes' to 'can start and control processes') you can craft a remote root exploit.

and the bootloader, which on a PC-type system can be used to gain root by booting into single-user mode.
Assuming the administrator did not apply a bootloader password and BIOS passwords (to prevent booting from other media).
However, physical security is not sufficient to prevent 'local exploits', and methods that can be used where there is lack of physical security are a bit off-topic for this story..

VAXen by tepples · 2012-01-25 15:29 · Score: 1

Some of them rhyme with VAXen though.

Re:Local exploit? by bmo · 2012-01-25 16:48 · Score: 2

>And I throw up a little in my mouth whenever somebody says or writes "boxen."

Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen!

Here's a mopxen!

--
BMO - Atinlay igpay oxenbey!

Holy by jimmydevice · 2012-01-25 16:53 · Score: 1

/dev/kmem and 4.2 BSD spy program batman!

What'd "//" be ? by aglider · 2012-01-25 19:48 · Score: 4, Informative

/proc//mem

is the very wrong quotation!
The original source quotes instead:

/proc/<pid>/mem

which is the memory as seen by a certain process whose PID is <pid>.
Moreover, there's no "/proc/mem" file and the "//" whould be interpreted as "/".
But maybe that'd be just the Slashdot editor.

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.

Re:What'd "//" be ? by mx+b · 2012-01-26 03:41 · Score: 2

I think /. simply ate the greater-than and less-than signs and everything in between, thinking it was an html tag.

Re:Better than Windoze by Tim4444 · 2012-01-25 21:00 · Score: 4, Insightful

You seem to be in a situation where PEBKAC - it's corrupting the text of your post. Of course what you meant to say is that the Open Source model does not guarantee security but simply allows interested parties to audit for and fix security problems independent of any single company or other rights holding restricting access to the source. Generally we find that the Open Source model has worked well for Linux and has been effective at addressing security concerns. The question is sometimes not whether problems exist, but whether or not they are found and corrected.

Speaking of security on Windows - if that post of yours isn't a case where PEBKAC, you might want to install some anti virus software - looks like someone might have pwnd your machine.

Yup by ThatsNotPudding · 2012-01-26 00:50 · Score: 2

Have you vetted your x86 CPU vendor's microcode for correctness?

I have a certificate signed by the PRC themselves, though I am struggling a bit with the Mandarin.

Re:Organized trolling campaign by GreatBunzinni by dave420 · 2012-01-26 01:14 · Score: 1

Yes, but that doesn't automatically mean anyone saying something that a "shill" might possibly say is actually a "shill". That's how bat-brained conspiracy theories start.

Re:Organized trolling campaign by GreatBunzinni by hairyfeet · 2012-01-26 02:16 · Score: 2

Well can we all agree now that an unpatched OS, no matter if its OSX, BSD, Windows OR Linux, is a bad thing? Because i am really tired of posting how much trouble i'm having with updates puking on drivers only to get told "Well just disable updates and the sell the machine! Nothing will go wrong, its Linux!". There is NO "magical OS" that is immune to exploits, none. In the past couple of years we've seen Windows, Linux, Android, iOS, every OS of any popularity at all has been pwned at least once, most several times.

so can we please put the lie to bed that you can run unpatched Linux systems and never have to worry, please? Oh and for those that say "nobody would say that" i got that same answer not an hour ago so this belief is apparently common, scarily enough.

--
ACs don't waste your time replying, your posts are never seen by me.

Re:iOS now has more marketshare than Android by Ash-Fox · 2012-01-26 02:17 · Score: 2

It's official: iOS now has more marketshare than Android.

Your article references the U.S. only. You do know there is more countries than just the U.S, right?

--
Change is certain; progress is not obligatory.

Why have the node be writeable by anyone but root? by Marrow · 2012-01-26 10:01 · Score: 1

What programs depend on it to be writeable? Just make the file read-only for the PID owner.

Re:iOS now has more marketshare than Android by Ash-Fox · 2012-01-26 11:24 · Score: 1

You're not suggesting those other countries actually matter, are you? What century are you living in? :-)

Not the century one that forgets where the majority of the world's population or where the strongest currency is.

--
Change is certain; progress is not obligatory.

Re:iOS now has more marketshare than Android by tqk · 2012-01-27 18:20 · Score: 1

You're not suggesting those other countries actually matter, are you? What century are you living in? :-)

Not the century one that forgets where the majority of the world's population or where the strongest currency is.

China? Really? The country with the most worthless people (per capita)? Doin' the math, ... One country / 7 billion people ...

Do any individual Chinese citizens amount to anything worth your consideration, or do you just throw them into the meat grinder as usual AS CHINA HAS FOR THE PAST FOUR THOUSAND YEARS? To the PRC, I'm wondering. Sorry, venting, I may have issues.

BTW, I do have Chinese friends. Some of them are fairly special to me.

Damn, I'm looking forward to seeing you asshats in the crosshairs of my sniper rifle. Now why does "People's Republic of China" make me giggle so hard?

Oh yeah. Mao Tse Tung!

You know where to find me, and the sooner the better.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:iOS now has more marketshare than Android by Ash-Fox · 2012-01-27 23:50 · Score: 1

Damn, I'm looking forward to seeing you asshats in the crosshairs of my sniper rifle. Now why does "People's Republic of China" make me giggle so hard?

Your assumptions amuse me, mistakening me for Chinese.

--
Change is certain; progress is not obligatory.

Re:iOS now has more marketshare than Android by tqk · 2012-01-28 05:00 · Score: 1

Pardon me, but I'm going to go watch Firefly now, as it appears none of you make any sense. Bye.

But.. but... how can you watch Firefly when Nielsen and NPD confirm that people buy cellphones? :O

This NPD? "NPD is a large polling company that that helps other companies report information about public. occationally they mess up really bad"

Wow. There is one hole hell of a lot of "FAIL" in there.

I need a new wristwatch... one with a stockmarket ticker... so I know with which mp3 player i"ll father my next child..

I believe you just proved my original point.

I think I'll go look for willing clitorises to pleasure now, toodles. [I believe the world would be a much better place were my tounge pleasuring more clitorises (but that's just my opinion).]

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:iOS now has more marketshare than Android by tqk · 2012-01-28 05:07 · Score: 1

Your assumptions amuse me, mistakening me for Chinese.

Yeah, I've got to admit, that looked pretty strange to me too this morning. I'll go find a wall to bang my head on now.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Two can play at that game by Barbara,+not+Barbie · 2012-01-30 04:22 · Score: 1

definition of obscure
12: to conceal

Concealing your password (as opposed to sticking it on a post-it or in your signature) is very much "security through obscurity."

That you can't understand that all security ultimately is based on something concealed is sad - it means you'll believe that things like biometrics are secure, when they're not (and they're also very much based on hiding something, both at the design and implementation levels, as well as the user level. If I have the information needed to duplicate your fingerprint, or the information on the data stream between the fingerprint reader and the rest of the system as well as the information on how to insert data into that stream, and the datastream that would result from your fingerprint, your data is mine).

There is no such thing as something that is 100% secure, but every bit of hiding (obscuring) information helps.

--
Let's call it what it is, Anti-Social Media.

Re:Two can play at that game by crutchy · 2012-01-31 19:44 · Score: 1

i've already acknowledged multiple definitions of "obscurity".

at the end of the day though, the accepted industry definition only relates to the one I put forward, which is quite acceptable (it still fits into a definition, even if its not the one you like best).

That you can't understand that all security ultimately is based on something concealed is sad
but I do understand that security is based on something concealed. what i'm trying to get you to understand (among other people who have apparently also been wasting their breaths) is that "security by obscurity" has an accepted meaning, and that not all security measures fit that meaning

Obviously there is no such thing as 100% secure, and obviously passwords are meant to be concealed, but "security by obscurity" is when the concealment IS the security measure.

Password concealment is part of the authentication process, but if a user gives away their password (removing the concealment aspect) it doesn't necessarily make the system itself insecure (it just offers access to whatever that password permits). Even if I don't know a password, if I know that I require a password, the security measure isn't concealed or hidden, so its not considered security by obscurity.

Why do you think most systems (such as online banking) are usually authenticated using a username and password combination rather than a unique complex URL with no password protection? Why do you think credentials are never passed as GET parameters in a URL?

Security measures considered "security by obscurity" are the ones that are bypassed when the security measure itself is discovered. If you do some googling you'll see what I mean.

Biometrics isn't security by obscurity because the security measure is obvious, but knowing how the system is secured still requires the necessary credentials (the correct fingerprint). The person whose fingerprint is required might be sitting next to you such that their fingers are in plain sight (no obscurity even by your own definition), but unless they put their finger on the scanner, you're still no closer to getting in.

You can either accept that passwords aren't "security by obscurity" or you can't. Even if you can't, it doesn't mean you're going to change the generally accepted meaning. It just means when you use the term in discussion with other geeks, you'll wind up being ridiculed for not understanding it to mean what is generally accepted.
Re:Two can play at that game by crutchy · 2012-01-31 21:32 · Score: 1

every bit of hiding (obscuring) information helps
"security through obscurity" is sometimes implemented in addition to authentication as part of "defense in depth"

an example of this (which fits the accepted meaning of "security by obscurity") is setting the "ServerTokens" directive in "/etc/apache2/conf.d/security" to "Prod" so as to hide the Apache version number in the default error pages... many webmasters do this, but only in addition to other security measures as required (not as their primary security measure). While not usually that much of an issue for up-to-date servers, setting "ServerTokens" to "Full" can help a potential hacker use exploits known for a version of Apache (a server in a datacenter might be updated on a schedule rather than whenever updates are released). If hackers can see your Apache version, they can look up the vulnerabilities for that version (below) and bust in.

http://httpd.apache.org/security/vulnerabilities_20.html
Re:Two can play at that game by Barbara,+not+Barbie · 2012-02-01 16:43 · Score: 1

what i'm trying to get you to understand (among other people who have apparently also been wasting their breaths) is that "security by obscurity" has an accepted meaning, and that not all security measures fit that meaning

I'm well aware of it - and I think it belongs in the trashbin, along with "best practices" (which is an excuse not to fix things because they're "good enough" - which is why Gates used it so often when people complained about the suckiness of Windows - "we use industry best practices."). Falling back on the "accepted meaning" rather than taking the opportunity to explore preconceptions is an "argument from authority" - same as religious people do with the bible. Nothing wrong with that, but it doesn't mean I have to go along with it, hmmm :-)

--
Let's call it what it is, Anti-Social Media.
Re:Two can play at that game by Barbara,+not+Barbie · 2012-02-01 16:47 · Score: 1

Or you could do like I did - served up a custom 404 that I copied from a windows error page on the net ... it's fun to look in the logs (so much so that I also made a fake directory listing page to serve up to make them feel like they struck paydirt once in a while).

--
Let's call it what it is, Anti-Social Media.
Re:Two can play at that game by crutchy · 2012-02-01 18:17 · Score: 1

its just terminology, but using accepted jargon will get your message across easier. it doesn't have to change how you go about security. i use some security by obscurity measures, but only on top of authentication and hardening. its easy to spend a lot of effort on security and still get hacked, so most people rely on "best practices" to come up with a practical security solution that will cover the typical threats but won't be prohibitively expensive (no point in making a really secure product that nobody can afford). the other advantages of especially written best practices (such as ISO standards) is that they give you a legal leg to stand on if and when you do get hacked, whereas any novel solution that you might come up with will have to be defended in court.
Re:Two can play at that game by crutchy · 2012-02-01 18:24 · Score: 1

Good one :)

I'm a bit lazy, though I have intercepted some bots (using PHP's $_SERVER["HTTP_USER_AGENT"]) and served them up cute messages before.

Slashdot Mirror

Exploits Emerge For Linux Privilege Escalation Flaw

103 of 176 comments (clear)