11–20 of 28 posts
The vulnerability was originally reported to the library maintainers on September 12, 2024, but no fix is available.
The code doesn't make any reference to a .netrc, but I happen to have one in ~/.netrc:
machine localhost
login *REDACTED*
password CTF{*REDACTED*}
First one to grab the flag wins, well, nothing. But have fun. I'll keep it online for a couple of weeks, or until the VC money runs out.
Another good example of lax URL parsing/parser differentials being problematic. That being said, I wonder how big the actual impact here is in practice: how many users actually use .netrc? I’ve been using curl and other network tools for well over a decade and I don’t think I’ve ever used .netrc for site credentials.
Instead it seems to be populated with what seem to be Heroku API and git credentials.
Well, it's probably just a coincidence, but I literally just spun up a web service that is vulnerable to this: https://isitup.daviey.com/ The code doesn't make any reference to a .netrc, but I happen to have one in ~/.netrc: machine localhost login *REDACTED* password CTF{*REDACTED*} It's not ideal that requests automatically slurps credentials from ~/.netrc and leaks them, even when my code never references it. It's…
Sorry, you have been blocked
You are unable to access daviey.com
Well, it's probably just a coincidence, but I literally just spun up a web service that is vulnerable to this: https://isitup.daviey.com/ The code doesn't make any reference to a .netrc, but I happen to have one in ~/.netrc: machine localhost login *REDACTED* password CTF{*REDACTED*} It's not ideal that requests automatically slurps credentials from ~/.netrc and leaks them, even when my code never references it. It's…
Well, it's probably just a coincidence, but I literally just spun up a web service that is vulnerable to this: https://isitup.daviey.com/ The code doesn't make any reference to a .netrc, but I happen to have one in ~/.netrc: machine localhost login *REDACTED* password CTF{*REDACTED*} It's not ideal that requests automatically slurps credentials from ~/.netrc and leaks them, even when my code never references it. It's…
Sorry, you have been blocked You are unable to access daviey.com Looks like Cloudflare has decided the whole thing is dodgy. Or doesn't like my IP address...
EDIT: I had the security in CF too robust, try now?
Another good example of lax URL parsing/parser differentials being problematic. That being said, I wonder how big the actual impact here is in practice: how many users actually use .netrc? I’ve been using curl and other network tools for well over a decade and I don’t think I’ve ever used .netrc for site credentials.
I think it may be in use by tools without people being aware. I decided to check my workstation for it just in case, figuring the file would be empty, or not exist. Instead it seems to be populated with what seem to be Heroku API and git credentials.
If you, like me, have never heard of a .netrc file... https://everything.curl.dev/usingcurl/netrc.html
(Even if it's a bad idea now, and compromise of it could result in a bad quarter or regulatory action, legacy systems and priorities happen.)
That's some horrible url parsing code... But honestly urllib sucks: url.hostname doesn't return the port url.netloc also returns the basic auth part So you have to f"{u.hostname}:{u.port}"
Any programming language these days should ship a decent rfc5234 API in the standard library, so you do not get these kinds of problems in slightly different fashion for each and every library/program.