Hacker News new | past | comments | ask | show | jobs | submit login

This feels a little bit like a naughtily published zero-day exploit.

I'm disappointed the post doesn't mention any appropriate disclosure to Apple prior to publication. Sure, it's not an out-right crack of the shaddow password algo but this vector could still be used in damaging ways.




Apple doesn't compensate security researchers, so I am not disappointed or surprised. In fact, they just ignore people half the time.

If it was a bug in a Google product, you can bet that he would have coordinated his disclosure with a fix.


Totally agree with this. Apple really ignore most security advisories, and I am speaking from experience.


Just from looking at Apple’s security page, it’s pretty clear they don’t ignore security issues: http://support.apple.com/kb/HT1222. Organizations and researchers are even acknowledged in the release notes: http://support.apple.com/kb/HT4826.

Like a lot of things, Apple does things quietly and on their own schedule without a lot of hoopla.


Compensation is irrelevant - if you bothered to sniff around a specific vendor's security and you discover an exploit then you really should disclose it. Such is the lore of white-hatism.

Sure many don't do the above, but the OP author is presenting himself as white-hat/legitimate.

And as informed users, we should consider carefully giving our business to vendors who don't go out of their way to encourage private disclosure --- a zero-day on a vendor is a zero-day on all of it's customers.


Sorry, but no. Compensation is highly relevant. Do you work for free? Or do you just not consider security research to be worth anything?

Although there are various opinions on the best way to disclose bugs, your view of what it means to be "whitehat/legitimate" is not actually consistent with the infosec industry, so please do not misuse the terms to throw judgments at others.

We can easily spin it the other way too after all - one could say that the largest, most profitable company in the world has a moral obligation to compensate those that are protecting their users where they failed to.

For reference: http://www.digitalbond.com/about-us/vulnerability-disclosure... http://erratasec.blogspot.com/2011/09/finally-responsible-di... http://www.securityfocus.com/brief/933 http://trailofbits.com/2009/03/22/no-more-free-bugs/


Yes I do work sometimes for free - its called Open Source - and sometimes I see my labor implemented into commercial projects. That's fine by me. I take from the well more than I give to it.

I entirely agree that Apple should be compensating those that disclosure exploits appropriately - I didn't say otherwise. But if you have a status quo where a vendor won't compensate and you have a zero-day opportunity, I say the appropriate thing is to inform the vendor first anyway (you can always disclosing publicly if you get no response). I fight for the user and all that.

Disclosing it publicly zero-day doesn't make you any money anyway.


Full disclosure is the only responsible sort of disclosure.

Apple, like Microsoft, has the tendency to sweep things under the rug when they feel it is unlikely the situation will become public. The only way to correct this behavior is release what you find to the public and as fast as possible.


Hmmm, surely 'Responsible Disclosure'[1] is the only responsible sort of disclosure - so named because it is, er, responsible.

[1] - http://en.wikipedia.org/wiki/Responsible_disclosure

TL:DR of above link: "[responsible disclosure] is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details"


It should be noted that anyone can edit wikipedia, and this pejorative term has fortunately been rejected by researchers and vendors alike. Even by Microsoft: http://www.theregister.co.uk/2010/07/22/microsoft_coordinate...

I've pasted some other definitions of "responsible disclosure" in a different reply.


Just because they call it "responsible disclosure" doesn't mean it is responsible.

I can call myself a shark. That doesn't make it so.


Not really. There's no privilege escalation. You can only change user's password if you're already logged-in as user. That's bad, but it's only going to happen if you literally walk away from a terminal and someone else sits down.


Actually. Any application can do this and use the new password to become super-user. Really useful for a virus I reckon.


How? The problem he mentions at the end of the post only applies to the currently logged-in account. If you can change root's password, then you're already root, and don't need to change root's password to gain access.


Exactly how can it use the new password to become super-user? You can't assume that everyone runs only the default admin user on their OS X system.


If sudo works the same way on Mac's as it does on Linux, then anyone in the sudoers file could give a rogue application root access.


It does, and, the only user there, by default, is the first user of the system - the administrator. Not all people use this as their main user.


By default, most do, and what happens by default is what matters to virus writers.


The file includes all password hashes, including root. So crack that, then you have superuser.


By default, Mac OS X disables the root user: http://support.apple.com/kb/ht1528

That said, reset or crack any admin's password and you can go to town with sudo.


Default user can use sudo with it's password. That's all you really need.


Not everyone, but I'd reckon MOST people do.


Or run a malicious script?


There are far more damaging "malicious scripts" one could trick someone into running, such as "cd; rm -rf *".

Like I said, it's not good, but it's not what I would call a "security hole" because there is no escalation of privilege. I like Raymond Chen's take on the topic: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...


"Like I said, it's not good, but it's not what I would call a "security hole" because there is no escalation of privilege."

Doesn't the end of the article suggest that without admin access, you could just reset the password for any admin user, then be able to log in as them? Sounds like priv escalation to me.

Edit: Actually, reading further comments, it seems you can only reset the password of the currently logged in user without reauthentication, so you can only get admin privs if you've already got a console with admin privs. I'm wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: