Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent • Hacker News Board

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#101

Post by neandrake » Thu, Mar 28, 2019, 4:44 AM UTC

0xcde4c3db wrote: post #53

danso wrote: post #8

Of all the security post-mortems I’ve ever wanted to read, it’s sad I’ll probably never get to read this one and its tale of how a team of well-paid comfortable engineers got together and decided this patch was a good idea.

Having been involved in meetings where "stop ship" was the phrase of the day, I'd bet money that the following at least vaguely resembles a real conversation: Engineer Alice: We should really fix this properly. Manager: How sure are you that the proper fix won't break something else for $BIG_CUSTOMERS who are responsible for $OBSCENE percent of this product line's revenue? Engineer Bob: Uh, ten percent on a good day?…

Manager: Bob get to work on the quick fix that will mitigate some of the attacks based on the published exploit to go out within a day, Alice get to work on the correct fix to address the underlying issue to go out in a few weeks when it's fully tested and ready.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#102

Post by saagarjha » Thu, Mar 28, 2019, 4:48 AM UTC

olliej wrote: post #92

MiddleEndian wrote: post #20

User agents shouldn't exist any more. They serve only to help unsuspecting users be fingerprinted.

Well, the next best thing is what webkit is doing ( https://webkit.org/blog/8042/release-notes-for-safari-techno... ) by freezing the user agent. So as time goes by the user agent becomes increasingly homogenous and so, less useful for tracking.

I believe this change was rolled back, since my User Agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.2 Safari/605.1.15".

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#103

Post by tbodt » Thu, Mar 28, 2019, 4:48 AM UTC

xnaas wrote: post #78

rndgermandude wrote: post #74

Earlier quoted context omitted.

You just wait for Edge-based-on-Chromium's User-Agent :D

Per a buddy who is using said Edgium (Chromium-based Edge): https://i.imgur.com/p6ZMoJY.png

Edg?

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#104

Post by witten » Thu, Mar 28, 2019, 4:52 AM UTC

neandrake wrote: post #101

0xcde4c3db wrote: post #53

Earlier quoted context omitted.

Having been involved in meetings where "stop ship" was the phrase of the day, I'd bet money that the following at least vaguely resembles a real conversation: Engineer Alice: We should really fix this properly. Manager: How sure are you that the proper fix won't break something else for $BIG_CUSTOMERS who are responsible for $OBSCENE percent of this product line's revenue? Engineer Bob: Uh, ten percent on a good day?…

Manager: Bob get to work on the quick fix that will mitigate some of the attacks based on the published exploit to go out within a day, Alice get to work on the correct fix to address the underlying issue to go out in a few weeks when it's fully tested and ready.

Manager: Alice, yeah, I know I said we'd carve out time this sprint for you to work on the long-term fix. But this other hot feature request came in, and there's potentially a lot of money riding on getting it done quickly. So can you put off the long-term fix, maybe a week? Two tops. You can just put the ticket.. yeah that one.. back on the backlog. There you go. Thanks so much!

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#105

Post by inopinatus » Thu, Mar 28, 2019, 5:02 AM UTC

MiddleEndian wrote: post #20

User agents shouldn't exist any more. They serve only to help unsuspecting users be fingerprinted.

We sometimes render different HTML to handle browser and device behavioural variations, including FOUT-management variations in how they load assets that therefore can't be handled in JS even if we wanted to. Historically we also redirected to a pure HTML/CSS version of our tools when IE9 or earlier was detected.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#106

Post by Pxtl » Thu, Mar 28, 2019, 5:14 AM UTC

stavros wrote: post #3

I don't see what the fuss is about. This is an effective mitigation, given that software can't just arbitrarily lie about its user agent.

Well, they can, but first they have to flip the RFC3514 "Evil" bit.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#107

Post by rvr_ » Thu, Mar 28, 2019, 5:16 AM UTC

Don't blame the manager, the PO, the CEO. This is ABSURD engineering incompetence. The fellow that did that _fix_ probably had no idea how to properly solve the issue.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#108

Post by colordrops » Thu, Mar 28, 2019, 5:17 AM UTC

anyfoo wrote: post #71

StavrosK wrote: post #9

Earlier quoted context omitted.

How? Do you think developers would be so crazy as to add some sort of "--user-agent" option to software like curl that would cause arbitrary strings to be presented as the user agent? Why would somebody write software to do this, just go on the internet and tell lies?

Even without --user-agent, you can still pipe 'echo -e "GET ...\rnHost: ... "' through nc, or even telnet. Therefore, we obviously need to patch echo (and all echo shell builtins) to refuse to output strings containing "GET", "POST", "HTTP", or "Host:".

Ooh boy I'm imagining some bureaucratic version of an operating system that uses this sort of security up and down the entire stack like some rube Goldbergian contraption to whack a mole a particular vulnerability. Like an operating system designed by doctor Seuss.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#109

Post by Simple_Guy » Thu, Mar 28, 2019, 5:18 AM UTC

amalcon wrote: post #77

0xcde4c3db wrote: post #53

Earlier quoted context omitted.

Having been involved in meetings where "stop ship" was the phrase of the day, I'd bet money that the following at least vaguely resembles a real conversation: Engineer Alice: We should really fix this properly. Manager: How sure are you that the proper fix won't break something else for $BIG_CUSTOMERS who are responsible for $OBSCENE percent of this product line's revenue? Engineer Bob: Uh, ten percent on a good day?…

I've been Engineer Alice before (not with a security issue, but a pretty bad systems issue). In case anyone is ever in that situation, here are some more productive replacements for that existential sigh (in that they sometimes work). Choose the one most suited to manager's biases. The cliches are important: think of it as giving manager an easy way to explain it to their manager. > Yes, but that would only help with…

Or you can just do the minimum just like the manager and cruise on the ship until it sinks while surveying for another ship to jump on at the first opportunity.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#110

Post by Quekid5 » Thu, Mar 28, 2019, 5:19 AM UTC

anyfoo wrote: post #84

amalcon wrote: post #77

Earlier quoted context omitted.

I've been Engineer Alice before (not with a security issue, but a pretty bad systems issue). In case anyone is ever in that situation, here are some more productive replacements for that existential sigh (in that they sometimes work). Choose the one most suited to manager's biases. The cliches are important: think of it as giving manager an easy way to explain it to their manager. > Yes, but that would only help with…

No! The answer is an unequivocal “No“, without any „but“s or anything like that. The fix does not fix the problem, it is not even a fix, just a wrong code change that sets out to do something but does not achieve it. Answering „yes“ is a lie here. This is different from a fix that fixes the problem in an ugly way, where „yes, but...“ is applicable.

Indeed, and what's worse is that many managers[1] will stop listening after "Yes, ...".

[1] The incompetent ones, of which there are many.