This is the vulnerability that had curl maintainers cut an early release, slated for October 11.
github.com/curl/curl/disc…
github.com/curl/curl/disc…
The test data included in the patch makes it clear enough to poke and play with this. 
For some super quick local testing, you can slap up a simple SOCKS5 proxy kudos to "pysoxy": github.com/MisterDaneel/p…
And sure, you can stage a dumbo easy redirect (php -S 0.0.0.0:8000 or whatever) and then use curl to drive through the SOCKS proxy to that redirect....
And yeah, you can use curl with -v to see the same error message that was patched out from the diff, so we're in the right spot...
But, if the risk is supposed to be curl switching to local resolve...
Maybe I'm dumb, but what damage does that do?
Sure you could append in some local resources you might "enumerate", but couldn't you already do that with SOCKS to begin with?
Maybe I'm dumb, but what damage does that do?
Sure you could append in some local resources you might "enumerate", but couldn't you already do that with SOCKS to begin with?
It's not ever likely for there to be a local name with over 255 characters, right? So you'd drive to a new location with @ if the goal to enumerate local resources, but how is that any different than just reaching that in the first place?
How do you actually weaponize this?
How do you actually weaponize this?
I'm out of my element at this point so forgive my nonsensical garbage babble, but, since it does store the whole hostname in a buffer, you could presumably do some funky stack stuff.
With a 2036-character long URI, it looks to be the limit of what is displayed in verbose info
With a 2036-character long URI, it looks to be the limit of what is displayed in verbose info
kek, could force a URL too long or drain memory
• • •
Missing some Tweet in this thread? You can try to
force a refresh
