Security Flaws: AFP-over-SSH Broken
After a discussion with Rich Mogull, where we both agreed that AFP is a threat (note that Apple fixed 4 different AFP threats in Security Update 2006-004), I decided to require ssh tunneling for AFP connections to www.reppep.com. Apple provides a neat feature for automatically tunneling AFP through ssh, but unfortunately it’s broken in half a dozen ways…
My initial report:
It is impossible to connect to an AFP server without access to port 548 — this should work if ssh is available, and AFP-over-SSH is enabled. Instead, with 548 blocked by a firewall, the AFP connection times out — even using an alias created when connected via AFP-over-SSH.
Connect To Server should accept afps://host as a scheme that specifies AFP-over-SSH. Instead it gets converted to afp://afps/host, which is wrong and nonfunctional.
It’s impossible to require ssh for AFP from the server.
It’s impossible to support AFP on the server without leaving port 548 open, even though with ssh tunnelling 548 shouldn’t be needed.
Note: These are not exploits, but they are real problems with the security of Mac OS X (Server & client).
An addendum:
Mac OS X client should be able to serve AFP-over-SSH. Now would be an excellent time to fix this weakness in X’s security posture.
Mac OS X client should be able to close firewall ports for active services, to force tunnelling; I’m particularly interested in ARD/VNC and AFP. Right now, any service enabled in Sharing must be open in Firewall (if the firewall is enabled through System Preferences). This should be optional.
Update, 2006/08/13:
I tried connecting through a manually created SSH tunnel, and it doesn’t work. Connect To Server doesn’t honor ports in the URL, so “afp://www.reppep.com:1548″ tries to find a machine named “www.reppep.com:1548“, which of course fails. This means a) I can’t do it without root-level access to create the tunnel on 548/tcp, and b) I can’t create the tunnel while File Sharing is on on the client (all my clients run Personal File Sharing).
Additionally, when I try to point Connect To Server to 127.0.0.1, it tells me “Connection failed” “This file server is running on your machine. Please access the volumes and files locally.”
It’s possible I could bind another interface on 127.0.0.2 and use “sudo mount_afp“, but that’s not even worth exploring. I cannot provide VPN access to all my users.
So AFP over the Internet is fundamentally broken, beyond any semi-reasonable means to fix. Please fix in Leopard!
edoug said,
December 11, 2006 at 10:20 am
I want to make sure I understand you properly, are you saying you think secure afp connections are broken, or that allowing their use does not guarantee their use? when i attempt a secure afp connection from Finder->Go->Connect to Server and use the options button to allow only secure afp it appears to work.
reppep said,
December 11, 2006 at 11:16 am
edoug,
If you manage to make an AFP-over-SSH connection, I believe you get full encryption for your file transfers. The problem is that it doesn’t work without AFP(-not-over-SSH) accessible to carry the initial connection, due to poor design.
This has two implications. First, this means I can’t provide AFP-over-SSH access without allowing users to connect via AFP without SSH — I want to require SSH for AFP, but Apple’s implementation doesn’t permit this. Second, I cannot simply firewall off port 548 without losing AFP entirely. Apple fixes major AFP bugs often enough that I don’t want that port exposed to the Internet. As a result I no longer allow my (Internet) users AFP access. That’s a shame.
RichardG said,
May 20, 2007 at 3:27 am
There is a work-round for this, you can add an extra IP address to the loop-back device and then forward AFP to that manually.
In terminal, type:
sudo ifconfig lo0 add 127.0.10.10 sudo ssh username@gateway -L127.0.10.10:548:remotehost:548
(you need to be super user to forward ports < 1024 , also to run ifconfig)
then in the finder, connect to afp://127.0.10.10
this lets me contact an AFP server behind a firewall that only allows through SSH. You can also SSH directly into a client machine and forward AFP over that link in the same way.
sudo ssh username@clientmachine -L127.0.10.10:548:localhost:548
though this lacks the Apple ‘it just works’ elegance…
reppep said,
May 20, 2007 at 8:31 pm
RichardG,
Does this actually work for you? First, I had to turn off Personal File Sharing on the client (since port 548 was in use). Once that was done, I ran “
sudo ssh -v pepper@www -L 127.0.10.10:548:localhost:548“, and the output included:I’d think this indicated 548/tcp was still in use on my client, but “
netstat -an|grep 548” indicates it is not.More to the point, when I try to make an AFP connection to
afp://127.0.0.1, I get the expected error message because the AFP client refuses to talk to myself:ExpanDrive - Secure Access To Remote Filesystems - The Apple Blog said,
December 7, 2007 at 11:41 am
[...] allowing remote SMB networking has a host of perils and secure, remote AFP connections have their own challenges. Isn’t there a simple and secure way to have share-like access to your remote [...]
DanBUK said,
August 28, 2008 at 5:03 am
Hey Reppep,
In order to get the tunneled version to work you must ifconfig first to add the extra address.
db:~ dbartlett$ sudo ifconfig lo0 add 127.0.10.10 db:~ dbartlett$ sudo ssh -L 127.0.10.10:548:REMOTEAFPHOST:548 dan@GATEWAYSSHHOST
It worked first time when I did both of those!
reppep said,
August 28, 2008 at 9:48 pm
Dan,
That’s a different issue. Mine is that the AFP client recognizes 127.0.0.* is the local host, and won’t let me connect back to myself.