[zaroth]

Normally I like bike shedding about bug bounty payouts just about as much as complaints about paywalls. If you are going to go poking around someone's code for fun or profit, the terms of the bounty program are readily available [1] so you can't complain after the fact for earning the maximum payout. LastPass isn't Facebook, and they never claimed they would pay more than $1,000 even for a full compromise or RCE.

On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!

[1] - https://bugcrowd.com/lastpass

[K0nserv]

The concern with the low payout is that it's supposed to be a way to compensate white hat hackers and dissuaded them from going to the black market with security problems like this. Given the business that LastPass is in wouldn't you agree that it's extremely crucial they make sure white hat hackers are aptly compensated for serious problems they find? In fact I'd think it'd be reasonable for them to pay more than Facebook for certain classes of bugs(like this one). After all all your passwords are more valuable than your Facebook account.

[tptacek]

No, that is not at all what a bug bounty is meant to do. We are not expected to pay people to avoid them launching criminal conspiracies against us.

The purpose of a bug bounty is to incentivize researchers to target specific pieces of software so that vendors can benefit from that attention.

[jontas]

Let's assume that there is a spectrum of honesty (say, from 1-10) and the pool of people capable of discovering vulnerabilities in your product includes people from the entire range.

If you're a 10 you will disclose responsibly regardless of a bounty, and if you're a 1 you will disclose to the highest bidder. The rest will weight profit, ethics, and risk in some ratio depending on where they fall on the scale and decide to act based on that calculation.

The company has to price their bounty on a few factors: how much they can afford to pay, how much a bug is worth to them (eg damage to their reputation, fines in the event of a vulnerability), and how important it is and to have researchers looking at their product instead of another product.

I agree with you that companies should not be required to pay people to prevent them from launching criminal conspiracies. But this is not a perfect world and people are not so black and white in their actions and motivations. There is no point trying to optimize your bounty program for the 1's or the 10's. Therefore, when optimizing for the rest it makes sense to pay as much as possible within the constraints I mentioned (in the previous paragraph) in order to tip the scales in your favor for the largest part of the spectrum possible. Right now the tech community knows about this problem with LastPass. If this exploit had made it to the wild things would've been much worse for them from a PR perspective.

I am hoping that the $1000 cap on the bounty program came from careful consideration of these factors, but my gut tells me it was a number handed down from management.

[Houshalter]

The point is to get more tens to even look at the code, not encourage people that have already found vulnerabilities to share them. I also think you vastly overestimate the percentage of criminals.

[K0nserv]

I think it's a bit of bucket A and bit of bucket B. Still even if one accept the definition you put forth the argument that having such low bounties makes LastPass look bad/like they're not caring is still valid.

[tptacek]

No, it is not at all "bucket A" and "bucket B", and suggesting otherwise is a grave insult to hundreds of researchers who would never dream of attempting (and, of course, inevitably failing) to "sell bugs to the black market". Finding interesting vulnerabilities in software makes you clever and talented, not sociopathic.

[lkbm]

> and suggesting otherwise is a grave insult to hundreds of researchers who would never dream of attempting (and, of course, inevitably failing) to "sell bugs to the black market".

No, suggesting otherwise is saying that a bounty program with high enough rewards can reach both legitimate security researchers and sketchy folks. This is in no way a slight on the first group.

[tptacek]

So the people on this thread saying that this particular researcher didn't get paid enough to "do the right thing" just mean that this person seems a little sketchy?

[cloudjacker]

What he's saying is "raise the bid"

Your rationale would be a valid rebuttal in your world no matter what the amounts in question were. $500? Incentive! $50? Incentive!

[tptacek]

This is a non-sequitur response to my comment, whose whole purpose is to point out that a bug bounty is not a bid in an auction against organized crime.

[cloudjacker]

You wish it was a non sequitur when it is completely relevant

We can agree to disagree because the perspective really wasn't for you, it was for everyone else reading that will share a sentiment they've felt but never articulated

[PeterisP]

In practice, in many cases, bug bounties are de facto a bid in an auction against organized crime. It doesn't need to be 1-to-1 equivalent bid, and it's not for all sources of found bugs, but the intent and the effect is definitely there.

[tptacek]

No, they are virtually never a bid against organized crime.

There are two kinds of vulnerabilities in the world:

The kind organized criminals will pay tens of thousands of dollars for, and the kind they, like any Internet rando, will pay $50 for lulz.

If you think this dumb regex bug is worth the same to organized criminals as a Chrome sandbox escape or drive-by reliable Flash RCE... well, people think that about a lot of bugs, I guess.

This LastPass bug is terrible. I was already inclined to warn friends against using it (but my other friends have beat me to that punch many times before). The bug looks terrible for LastPass and its mere existence is damaging to that project.

But that doesn't mean the bug has significant monetary value. As someone else here cleverly put it on the last dumb bug bounty thread: you can smash a car with a sledgehammer, but that doesn't make the sledgehammer worth the value of the car.

[zaroth]

There are many people capable of finding this specific bug and reporting it who might be motivated to take a look by a bug bounty, but who would never even consider trying to sell an exploit on the black market. I agree there is one cohort where you are trying to offer them an alternative to illegally monetizing their exploits. Then there is another cohort who you are just trying to encourage them to spend some time with your code versus someone else's. I could only guess at the relative sizes of the two groups, but the optimist in me thinks bug bounties are less about the former than the latter.

As we can see from avlidienbrunn2's response [1] sometimes it's not about the money. It's just fulfilling a natural curiosity about a product, maybe getting your killer write-up of a shocking bug to hit the top of the HN frontpage, etc. So in this case perhaps the bounty program is as much about establishing a legal structure for a whitehat to operate under than to fairly compensate ad hoc pen-testers. I wish they paid 10x or more for this bug. But I'm glad at least pen-testers can report these bugs without [as much] fear of reprisal.

[1] - https://news.ycombinator.com/item?id=12171753

[K0nserv]

I agree with the cohort theory, but to me it's not so much about the risk of someone selling an exploit on the black market, all though it's still a risk. To me it's more about how it reflects on a company where security is key to their product. Low bounties kinda gives of a vibe of not caring about the security of their product and maintaining it.

Personally I lost a lot of confidence in them when they got acquired and switched to 1Password, paying very low bounties for critical security flaws further hurts my confidence in them.

[tptacek]

Most companies, including companies far more security-sensitive than LogMeIn, pay no bug bounties at all. Meanwhile, the companies that pay the largest bounties are themselves routinely harangued online for underbidding the black market --- despite the fact that outbidding crime is in no way the purpose of a bug bounty.

From my vantage point, the logical conclusion to the comment you just wrote is that companies should avoid offering bug bounties. They just attract negative attention.

(I won't use LastPass, and have recommended 1Password --- but Tavis Ormandy is looking at 1Password right now, and I'm guessing they're going to end up disappointing HN too.)

[K0nserv]

It's true that not all companies pay bug bounties and you might very well be right that paying them, especially if they are much lower than other companies that operate bug bounties, might have a worse affect on public opinion then not having bug bounties at all. To me it's still concerning that Facebook pays 10x more for problems that are less severe and it does still make LastPass look like they don't care as much in comparison.

[tptacek]

If this was a thread about a Facebook vulnerability, the exact same things would be said about Facebook. To verify for yourself, use the search box at the bottom of the page to find a thread about a Facebook bounty.

[dzmien]

Wouldn't a true white hat hacker report the bug no matter what the bounty? Therefor, the bounty is in place to encourage black-hat hackers to report the bug instead of trying to profit from exploiting it. But I do agree that it is in a security company's best interest to offer high dollar sums for reporting crucial bugs. I am just arguing semantics :-)

[throwawayReply]

It isn't a choice between "bother to submit or not", it's a case of a white-hat might be encouraged to look into this product rather than another product because of the bounty.

So the end effect is more bugs found by "white hats" rather than "black hats" because the bounty has focused the "white hat" efforts on your program. (Or encouraged them to look at all.)

I'm likely to poke around a site with a bug bounty even with small sums just because it hints at a more formal process and also likely means they have a sensible policy about not going after testers.

Bug bounties are as much about signalling than encouraging "black hats" to suddenly turn to the light side.

[ufmace]

I mostly agree, but I would say that if the amount of a bounty affects your decision on whether to responsibly disclose it or sell to the highest black-market bidder, then you are at the very least a grey hat.

[jerf]

"On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!"

Why not? URIs are at least able to be tokenized perfectly well by a regular expression. You have to do it right, but there's little guarantee that your non-regexp code will do it right either. I glanced at that regexp and immediately recognized several potential problems with it... will I be able to do that with your non-regexp code?

To concretize the "several potential problems": 1. You generally don't want to parse arbitrary protocols, you should do something like (http|https|file) or whatever set of protocols you are ready to receive. Usually you're better off treating anything else as "not a URL", but consult your local security context for details. 2. Failing that, you want at the very least .⁎? to stop matching at the first :, or if your engine doesn't have that, the protocol ought to be matched with something much tighter like [a-z]+. And I do mean + and not ⁎, because you probably don't mean to support an empty protocol before the colon. (You may mean to permit URLs with no protocol, but that's (.⁎?:)? .) 3. Domains should be parsed more tightly than "not a slash". 4. Also, I have no idea what the @ was doing there. Perhaps it was trying to be $; URL parsing should always end with the "end of string" matcher to avoid problems similar to this. It should also start with the start-of-string matcher, which this one doesn't, for similar reasons. 5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this.

I literally saw all this faster than I could type it; does your non-regular-expression based code have this property?

Regular expressions aren't bad. They're hard to write properly, but still probably easier to write properly than anything else. It turns out the underlying problem is fundamentally hard.

(Had to use an alternate asterisk to get the RE expressions correct with HN trying to format it.)

[0xbadcafebee]

Heh.

https://mathiasbynens.be/demo/url-regex

https://lostechies.com/chadmyers/2010/11/20/parsing-a-url-wi...

https://stackoverflow.com/questions/27745/getting-parts-of-a...

What do all these have in common? They all demonstrate that it is hard to write a regex that parses URLs.

Regex's hide programming mistakes because they not only become harder for humans to parse as they get more complicated, but also there isn't simple programming code to handle potential security vulnerabilities in-line with the code. It also hides the [at least] two considerations of secure programming: designing a secure function, and handling the function securely.

[jerf]

It is hard to write code that parses URLs, period.

You can't look at regexs in isolation, see that a task is hard, then declare them unfit. You have to consider them as one of the many choices and analyze the cost/benefits of the whole suite of options.

I guarantee you that anyone who has said "Oh, gosh, this is hard, I'll just start using indexOf and substring operations" has written code that is just as broken, only in ways much harder to tell.

Which is probably why everyone here thinks it's better to not use regex. You didn't write better code... you wrote code that hid its brokenness better. That's not a good thing!

Again, my real point here is not "regexes are awesome in every way"... my point is that I literally glanced at that code and saw several ways in which it was wrong. Does your alternative have that property?

Also, some of the difficulties of regexes are accidental, not essential. Take something like the recent Perl 6 efforts for parsing and you're far better off in every way using that stuff than trying to bash together string-manipulation-based parsing, or whatever other alternatives you may be thinking of. The Perl 6 constructs will be more readable and more maintainable. (Perl 6 is crazy in a lot of ways but the parsing support is best-of-breed.)

[bad_user]

Regular expressions describe finite state machines and in programming there's nothing simpler than finite state machines / finite automatons. Your handling of vulnerabilities inline is anything but simple. This is CS 101.

[peterwwillis]

The handling of security is anything but simple. Hence, a simple solution is anything but secure. This is Security 101.

[bad_user]

I can't even parse that. First sentence is false. Second sentence wouldn't follow from it if it were true, but then a false sentence can imply anything. And I've literally taken Security 101 in college.

You might also want to check the definition of "simple". Probably doesn't mean what you think it means.

[pmarreck]

> using regexp to parse the URL

A while back I whipped this up: https://gist.github.com/pmarreck/2956396

which seemed to work well (although it was a bit slower, I probably didn't know about exponential backtracking at the time and that could probably be revisited). It won't gather multiple name/value pairs though, but it will cut out and name basically every other part of the URL.

[greendestiny]

Wait what?

"Why not? URIs are at least able to be tokenized perfectly well by a regular expression."

"5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this."

[jerf]

Encoding or decoding is not tokenization.

And the problem is probably more accurately stated as "be suspicious of any function implementing encoding or decoding" rather than focusing on the regex part. Use the correct standard function. Don't bash something together yourself. They're actually pretty easy functions to write if you know what you're doing, but it's even easier to use some tested already-existing function. In fact, it's so easy that the fact that you see someone bashing together a URL encoding or decoding function almost certainly proves that they don't know what they are doing, which in turn means the URL encoding or decoding function was written by someone who doesn't know what they are doing. Unsurprisingly, these are, well, to quote myself, "suspicious".

Yes, that logic applies to URL parsing as well! Unfortunately, browsers make URL parsing extra hard, which is really stupid, so you end up with more crap in Javascript than anywhere else. Even then you ought to prefer someone else's tested solution over just smashing out a regular expression; however, it is not a knock on the tested solution if it is a regular expression-based solution.

[ebbv]

> Why not?

This article is a perfect example of why not.

[icebraining]

you can't complain after the fact for earning the maximum payout

Why not? Sure, you can't accuse them of being dishonest, but why would simply announcing an action make it beyond reproach?