4 ms·
I feel like that (innocence about security) might be a bit of the reason why this vulnerability existed in the first place. I'm sure the NetAuthAgent code is ve
by nmgycombinator 2y ago
I feel like that (innocence about security) might be a bit of the reason why this vulnerability existed in the first place. I'm sure the NetAuthAgent code is very old, and was probably written at a time before even Apple was serious about security. And what really can you add new to a web server client? I wouldn't be surprised if the entitlement check is the first thing they've added to it in years.
It's funny, Apple themselves even suggest people use other apps for FTP:
https://support.apple.com/guide/mac-help/servers-shared-computers-connect-mac-mchlp3015/15.0/mac/15.0 https://support.apple.com/guide/mac-help/servers-shared-comp...
> With read-only access, you can copy files from the server, but to copy files to the server, you may need another FTP app. Choose Apple menu > App Store to find FTP apps available for macOS.
Another funny note: NetAuthAgent has had a bug for years where you cannot connect to an FTP server if your username contains an `@` symbol. I understand the technical reasons for that, but it is technically supported by the spec and other clients work with it just fine. I'd dig up some old posts talking about it going back years, but I don't want to put in the effort, lol.
- retox 2y ago>NetAuthAgent has had a bug for years where you cannot connect to an FTP server if your username contains an `@` symbol. Basic auth and FTP had a username password schema like ftp://username@ftpserver.address.com and even ftp://username:password@ftpserver.address.com
- nmgycombinator 2y ago> I understand the technical reasons for that, but it is technically supported by the spec and other clients work with it just fine. I am completely aware of that, but I am aware that other clients handle it just fine. The bug actually forced me to use a different client for when I actually needed an FTP client.
- hunter2_ 2y agoI would've guessed that once it's established that the bug is caused by the app injecting the specified username into the USERINFO portion of a URL without the necessary percent-encoding, a workaround (other than using a different client) would be to manually percent-encode the username, i.e., replace the "@" with "%40" ... although this wouldn't work if the app actually did percent-encode an entered "%" despite not encoding an entered "@"!
- nmgycombinator 2y agoFascinating. I'll have to test that out!