Date: Sat, 2 Jun 2001 10:06:30 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: "Karsten W. Rohrbach" <karsten@rohrbach.de> Cc: Kris Kennaway <kris@obsecurity.org>, Crist Clark <crist.clark@globalstar.com>, security@FreeBSD.org Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <Pine.NEB.3.96L.1010602095828.46871a-100000@fledge.watson.org> In-Reply-To: <20010602155302.A56136@mail.webmonster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Jun 2001, Karsten W. Rohrbach wrote: > > Note that X11 forwarding has similar compromise properties, only it > > provides an even more direct path to the user's keying material. > sure thing. therefor i propose X11forwarding to be turned off by default > in sshd_config and ssh_config. At this point, agent and X11 forwarding are both disabled by default in the FreeBSD OpenSSH distribution for that very reason. Many other distributions still enable them by default. We have them enabled on the server side, since generally speaking, these services are a risk to the client, and not to the server (at least one OpenSSH distribution has X11 forwarding turned off at the server to protect against a client-side attack :-). There are some resource allocation issues associated with enabling the services on the server, but as far as I know, not all that serious. > 1) we got a possible threat abusing the agent in several manners since > it dumbfire signs all challenges it gets, so: > - agent forwarding shoudl be turned off by default > - the agent must write a log file with the vital signing process > data, also syslogging would make sense sicne the admin could see > the messages, too > - the agent should get some instrumentation to process policies and > allow/disallow certain signing requests > - some popup/user intervention interface for signing challenge > packets would improve interactive use > - maybe it would make sense to have the agent evaluate the state of > the session for validity, this would be a big change in the agent > interface and most likely introduce new bugs Actually, what I'd like to see is a change in the RSA agent authentication such that the authentication can be performed against known host keys (making it a two-key authentication as opposed to a one-key authentication), meaning that (as long as the key is known to ssh-agent), the scope of an authentication could be reported when the agent is requested to provide authentication service. > 2) port forwarding poses at least a DoS threat, so this is turned off by > default > > 3) X11 forwarding also poses several threats and should be turned off by > default It's not clear how severe these threats are: it may be that the advantages associated with providing these services (since they are only provided to authenticated users) outweigh the resource costs. On the other hand, you could imagine introducing some policy enforcement relating to resources allocated to SSH sessions in global sshd configuration (max (n) forwardings per client session, etc, etc). > 4) i've seen several (other) os dirstributions allowing root logins over > ssh. these should also be disabled in the default config These are currently disabled by default on FreeBSD. > 5) all of the pkcs based auth is good in a trusted environment, but when > it comes to connecting to untrusted systems, s/key (or maybe opie) > will be a much more sensible choice. The advantages of one-time passwords often have to do more with administrative policy for the system performing the authentication, rather than for the client connecting, but the comment none-the-less applies. It should be noted that traditional authentication schemes have provided the administrator with the ability to enforce a variety of mandatory policies, but that SSH places an increased focus on the user managing their own authentication (by virtue of authorized_keys, etc). When defining policy and policy enforcement, we need to be very careful to avoid pitfalls associated with misunderstanding to whom particular benefits go (for example, the mistake of limiting X11 forwarding on the server, not the client -- a compromised server can always reenable X11 forwarding in negotiating with the client, and it was the client who was the victim of the attack). > 6) de-automation of certain ssh features would be a general objective to > work on, it will give the user more fine grained control over what > happens with his credentials This is certainly true: right now the policies associated with SSH are relatively hard to manage, and it's hard to bind policy to some tuples you'd like, including combinations of host and port, host and authenticated identity, etc. For example, you can imagine enabling SSH agent forwarding when logging in as yourname@somehost, but disabling it when logging in as ftp@somehost. Likewise, requiring different keys for yourname@host:8080, with different policy. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010602095828.46871a-100000>