Date: Tue, 17 Jun 1997 14:25:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ahd@kew.com (Drew Derbyshire) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: (Fwd) Re: Serious potential IMAP problem Message-ID: <199706172125.OAA19688@phaeton.artisoft.com> In-Reply-To: <33a5f31d.kew-sonata@sonata.uucp.kew.com> from "Drew Derbyshire" at Jun 16, 97 10:14:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Oh, it's our dear little pal Mark Crispin. He's such a charmer, don't > > you think? > > Suffice to say I did not find this comment charming. Me either. I've been having a productive dialog with Mark regarding the IMAP4rev1 (RFC2060) standard as it relates to server rather than client implementation (the standard appears to have an organizational bias discouraging server writers). There a number of other semantic nastinesses which require token stacks because of ordering issues (variant valued tags preceeding commands so that it is impossible to use alternate Lex start states to disambiguate them, and numeric values untagged responses preceeding identification tokens, etc.). Other than what I view as parser technology favoritism (the LISP model is a religious issue; he does not like Yacc/Lex generated LALR parsers), he has been quite reasonable in discussing these issues. > > > > In good operating systems, there is a non-root state which > > > > equates to being "not logged in"; it issue an unprivileged > > > > system call to log in with authentication credentials in > > > > the call. The kernel validates the authentication credentials > > > > and sets the process's user id on success. I don't like this statement, mostly because it puts a catch-22 on kernel service credentials potentially necessary for boot. Like NFS client services. It also precludes any reasonable method of obtaining priviledged credentials from a completely unpriveleged state. This seems to be a distinction of degree, not one of kind, and therefore an aritifical, puritanical requirement. This is not to say that there are not benefits to the NT security model; only that those benefits derive from implementation, not from the NT model itself. > > This in turn requires the kernel have the mechanism to access the > > credential store, which may equate to bundling every possible password > > access mechanism with the kernel; yeah, let's suck in all the Kerberos > > stuff, NIS, Radius, S/Key, ssh, Tacacs, SecurID, the Captain Midnight > > Secret Decoder Wheel algorithm, and so on. > > This is not correct. For example, FreeBSD file systems need not be > compiled into the kernel to be a system call. Likewise, IBM VM/ESA both > use external file systems and external security packages with well > defined API's which are routed through the kernel but run as started > (daemon) tasks, which would have the required access. The FS comment is a nonsequitur. I do, however, agree that the GSSAPI RFC1508 mechanisms referenced by RFC1731, and the RFC2095 improvement to the clear-text storage of the shared secret on the server are both logical FOR A SERVICE. However, I don't believe that a UNIX (or NT) kernel meets the RFC1508 definition of "application program". > Likewise, numerous systems allow processes acting as "nobody" to execute > commands (login, date, time, in some cases message) which in the case of > a command allow the priv level to be upgraded. Priviledge upgrade by an unpriviledged user is problematic. I *certainly* do *NOT* buy the NT GINA model access via "impersonate" as a very secure mechanism. In general, the MS API's are geared toward *downgrading* security for services started by a process with administrator credentials. Unlike "secure UNIX" and "VMS installed images", the NT model is a poor cousing, in that it requires initial trust (just as with the UNIX login model). > > You'll note that there's no actual attempt to justify why > > authentication by root and subsequent sacrifice of priveledge is > > actually _bad_. > > This is fairly clear to me -- one never wants to grant more access than > is needed, because if excessive access is never gained, it cannot be > abused by programming error or attack before being surrendered. It also > discourages the practice for every setuid program to have direct access > to the sensitive security database. Agreed. But NT is hardly the shining icon to hold up as the "Gold Standard" of such implementations. Clearly, the NT mservice model and external authentication replacement via GINA, in particular, was not well understood before the posting was made. The IMAP4 code from the University of Washington provides imap2/imap3 compatability, both of which require priveledged port access, and I believe the IANA target port for imap4 is also priviledged. In addition, the IMAP4 code, when compiled for NT, has no GSSAPI knowledge of the NT authentication services (via GINA), and provides only LI compliance for authentication (ie: only support for the "LOGIN <user> <password>" facility) on NT. Aside: I can easily crash NT with a user space program of any credential; it is not a far logical leap to me using this not to execute unintentionally erroneous code resulting in a crash, but to instead execute intentionally erroneous code to result in a security breach. The only thing preventing this at present is that I do not have the patience to wade through WinICE to determine the correct incantations. There are doubtless others in the same situation who either *do* have the patience, or who could be paid to act as if they has the patience for sufficient time to complete the task. In the limit, NT *is* crackable by any low priviledged credential with patience (or money, in lieu of patience). > > Alternatively, consider using the PAM framework, which is compact, > > open to analysis, and once analysed, every program that uses it is > > much simpler to analyse in itself. If PAM interests you, see the > > references off my homepage (http://www.smith.net.au/~mike). > > As shared library(s), it still appears to encourage granting root to a > program as trivial a POP3 server which only needs normal user access. > This temporary root access is, to me, inherently more dangerous than > taking a program from no access to the specific user id without a stop > at the higher priv level. I believe there is, implicitly, a stop at a higher level when the user traps to kernel mode for the call. Kernel mode does not even enforce page write protection against kernel services for many Intel processors. It seems to me that the original NT security assumptions are flawed in this regard, even were *all* the system call bugs found and repaired (unlikely in the lifetime of the universe, given most software developement teams' resemblance to road construction crews). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706172125.OAA19688>