Pam-ussh may be tricked into using another logged in user's ssh-agent | Hacker News Reader

Pam-ussh may be tricked into using another logged in user's ssh-agent

hackerone.com

74 pointszdw24 comments

The bounty amount seems exceptionally low in light of the experience of the reporter, the security budget of the reportee, and the severity of the bug.

It seems to me another zero on the end would be appropriate.

Not to mention his extremely well founded comments on their patch.

High level consulting basically.

Fifteen thousand dollars to report a bug in a PAM module that you need a local account to exploit? That is excessive. I don't think a professional would get paid that much for an audit of the project (and they didn't hire one, this just one bug report)

$15k sounds about on the money for the consulting project to assess pam-ussh. But I agree that it's a silly amount for a bounty.

The actual bounty was $1,500, not $15,000: https://hackerone.com/reports/204802#activity-1513764

Yes. The parent-parent said "It seems to me another zero on the end would be appropriate. "

Perhaps one day I'll learn to read. Sorry 'bout that.

The public release of the report (where the bounty hunter talks extensively about the right and wrong ways to fix the issue) is a nice feather to put in your cap, even if the cash is not a lot.

Ah, the old "do-it-for-the-publicity" :)

What severity? It's an internal-only bug. There is literally no conceivable market for it.

I don't think Solar Designer even expected a bounty.

It's public code, for a PAM module that others might be using too. The attack isn't limited to Uber's infrastructure.

To the extent this is true, those others aren't paying the bounty. Uber, who is paying, probably has fairly limited exposure to the bug; i.e. one insider impersonating another. To return to the main point, who exactly would pay more for this bug and why?

Funny, one of our engineers at ScaleFT reported the same issue 24 hours later.

He'd solved the same problem before:

https://github.com/jbeverly/pam_ssh_agent_auth/blob/master/a...

Apropos whatevs, that is some wild indentation. The block at the bottom, that actually does the connect, none of the code after the if is what it looks like it is. If you know the author, might mention this.

Wow! That bug report and follow-up is absolutely amazing!! If anyone is ever trying to convince a company to release code as open source, this is the best possible example to give.

I highly recommend avoiding PAM if you care about security.

Also, was this written because pam_ssh_agent_auth does not support certificates specifically? If so, why wouldn't they just modify the existing module? Another example of "Hey let's re-engineer the wheel for fun" ?

Then OpenSSL environment variables are security vulnerabilities too? https://news.ycombinator.com/item?id=13558750

Not by themselves, but they could be part of one in a specific scenario.

js; dr

I copied the content here for anyone in a similar situation to the parent commenter: https://justpaste.it/14pz7

The HTML hidden in that mountain of div tags is remarkably well formed for the standard I see around on the "modern web".

True. But it is ironic for a site named "hackerone.com" to serve nothing with Javascript blocked. Or maybe just a bad joke ;)

Please don't do this here.

To expound on this: It's nearly unconscionable for a security-oriented site to mandate JS for basic functionality. There were no alternatives provided, the noscript blurb did not offer a list of domains which were serving the JS, there was no fallback rendering, and so we are forced to trust an unknown party to execute code in a leaky ambient jalopy of security failure.

If we stop pointing this out, then we lose.

Reply on news.ycombinator.com