Path: news.mitre.org!blanket.mitre.org!philabs!newsjunkie.ans.net!newsfeeds.ans.net!news-was.dfn.de!news-kar1.dfn.de!newsfeed.nacamar.de!wnfeed!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!news.sprintlink.net!Sprint!worldnet.att.net!nntprelay.mathworks.com!news.mathworks.com!mvb.saic.com!info-vax From: Jerry Leichter Newsgroups: comp.os.vms Subject: Re: vax/vms security holes Message-ID: <9801030535.AA00161@uu3.psi.com> Date: Sat, 3 Jan 98 00:19:59 EST Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Lines: 238 I should explain -- under unix, the system call interface defines how system resources are accessed. As far as user-mode code is concerned, the system is a black box. That's not true of VMS where many system resources share the same address space, This is equally true of all modern Unix implementation I know of. and often user-readable. This, at worst, allows violations of privacy - i.e., you may be able to read stuff about another process. But read-only access doesn't let you change anything. In fact, I can't recall ever hearing of a privacy violation in VMS that resulted from this (in the sense that there was something you could read that the design didn't deliberately make available to you). Mainly, this is because most readable "system stuff" is in process space, hence is about your own process. The "sensitive" stuff that actually lives in S0 isn't accessible from user mode. Even so, Alpha VMS is quite a bit more restrictive than VAX VMS. That makes life a lot easier if you're trying to fool a system call into accidentally-on-purpose overwriting your privilege mask... (I've seen this done.) I don't see the connection. Where do you think the euid/egid for a Unix process live? Traditionally, they're in the u area - which by its nature has to be mapped into the process's virtual address space. What's worse, a lot of stuff is buried in VMS inner-mode code that under other OSs is done in user-mode daemons. Such as? I can't think of any significant examples in mainstream Unix implementations. Mach is another story; it was *designed* to have most things done in user-mode daemons, a reaction to the perceived problem that Unix kernels were growing without bound, with everything being dumped into them. In fact, however, the initial implementation of the Unix emulation subsystem for Mach had a single server process that contained most of a Unix kernel - spliting up Unix functionality wasn't easy. Later versions did split things up - but the performance wasn't good. This is no longer considered a viable alternative. (Besides, the only Mach-derived commercial Unix is Digital Unix.) means the line between system and user code is a lot longer, and has more fronts to be attacked on. That's on top of privileged images. (A quick count shows that protected and privileged images on my fairly vanilla VMS system outnumber setuid root programs on my fairly vanilla Unix system, by a small margin.) That's a meaningless comparison. VMS has put some stuff into protected and privileged images as a modularization technique. These are written and maintained as part of the kernel. (I'm not even counting execlets, which *are* the kernel; I don't know if they were part of your comparison.) Rather than talking in the abstract, let's look at a real system. Here is a list of all protected shared images on a (VAX) VMS V5.5-2 system. It's a pretty vanilla workstation. I've grouped them by type: Implementations of system services - i.e., things that are "the kernel under a different name": DISMNTSHR;3 Open Hdr Shar Prot Lnkbl MOUNTSHR;5 Open Hdr Shar Prot Lnkbl PTD$SERVICES_SHR;3 Open Hdr Shar Prot Lnkbl SECURESHRP;3 Open Hdr Shar Prot Lnkbl SPISHR;3 Open Hdr Shar Prot Lnkbl The Debugger system service interceptor. On Unix, the equivalent functional- ity is embedded in the ptrace() system call - i.e., in the kernel. DBGSSISHR;1 Open Hdr Shar Prot Lnkbl DECwindows stuff. I don't know what's in here or why it's protected. DECW$SECURITY;1 Open Hdr Shar Prot Lnkbl DECW$SESSIONSHRP;1 Open Hdr Shar Prot Lnkbl DECW$TRANSPORT_COMMON;2 Open Hdr Shar Prot Lnkbl DECW$TRANSPORT_DECNET;2 Open Hdr Shar Prot Lnkbl DECW$TRANSPORT_LOCAL;2 Open Hdr Shar Prot Lnkbl DECW$TRANSPORT_TCPIP;2 Open Hdr Shar Prot Lnkbl Special performance hack: Allows an unprivileged MAIL program (a) access to the MAIL profile database; (b) to write to other users's MAIL.MAI files. Pretty much the equivalent of setuid mail delivery agents. Note that what MAILSHRP does is *very* simple compared to what a full delivery agent does, so it's much easier to get it right. (In the history of VMS, as far as I know, there has been *one* security problem in MAILSHRP, and it would have been hard to exploit to do anything but clobber files.) (In a small range of VMS versions, MAILSHRP didn't check that MAIL.MAI was owned by the owner of the username to which it was delivering. Use your imagination to see where this can lead....) Compare this to the endless list of holes in sendmail. MAILSHRP;3 Open Hdr Shar Prot Lnkbl No idea what these are, but at least some are probably also implementations of system services: DTI$SHARE;1 Open Hdr Shar Prot Lnkbl EPC$SHR;1 Open Hdr Shar Prot Lnkbl INIT$SHR;3 Open Hdr Shar Prot Lnkbl IPC$SHARE;1 Open Hdr Shar Prot Lnkbl For programs installed with privileges, we get more of a mixed bag. Equivalent to suid daemons on Unix: EVL;3 Privileges = SYSNAM OPER SYSPRV MAIL_SERVER;3 Open Hdr Shar Privileges = SYSPRV NICONFIG;3 Privileges = SYSNAM LOG_IO PHONE;1 Open Hdr Shar Privileges = SYSNAM PRMMBX WORLD OPER NETMBX VPM;3 Open Hdr Privileges = SYSNAM PSWAPM ALTPRI TMPMBX NETMBX SYSPRV Equivalent of the suid login program on Unix: LOGINOUT;5 Open Hdr Shar Privileges = CMKRNL SYSNAM LOG_IO ALTPRI TMPMBX SYSPRV System management utilities. It's not clear to me why these have to be installed with privileges at all; they are most often run from SYSTEM anyway. In practice (a) these are owned by the OS group; (b) all immediately start off by checking whether the process has pretty massive privs - many SYSPRV - already, and immediately exit if it doesn't. As a result, it's hard to see any way these could be exploited. (Yes, bugs are always possible, but the simple nature of the startup logic makes them pretty unlikely.) AUTHORIZE;3 Privileges = CMKRNL INSTALL;1 Privileges = CMKRNL PRMGBL SYSGBL SHMEM SYSMAN;4 Privileges = CMKRNL System display stuff. In the same class with the Unix setuid ps program. SHOW;3 Open Hdr Shar Privileges = CMKRNL WORLD NETMBX SHWCLSTR;3 Open Hdr Shar Privileges = CMKRNL Various utilities to set things that can't be set directly from user mode. Unix equivalents would be things like the setuid passwd program. CDU;3 Open Hdr Privileges = CMEXEC SET;3 Open Hdr Shar Privileges = CMKRNL TMPMBX SYSPRV SETAUDIT;1 Privileges = CMKRNL DETACH PSWAPM ALTPRI SETPRV TMPMBX WORLD BYPASS SETP0;3 Open Hdr Shar Privileges = CMKRNL SYSPRV SETRIGHTS;1 Privileges = CMKRNL These last two groupings are *not* VMS's best bits of security design. CDU, as far as I can tell, needs enough privilege to change the command tables in supervisor mode. However, there's no CMSUPER privilege, so it has to get CMEXEC. The rest (except for SHWCLSTR) are intimately connected with DCL. It would probably have been better if SHOW were split into two programs, one of which did the non-privileged stuff (most SHOW commands), the other the privileged stuff. The same goes for SET. DECWindows stuff; no detailed idea what it's doing or why it needs privileges. DECW$SETSHODIS;1 Open Hdr Shar Privileges = CMEXEC DECW$WINMGR;2 Privileges = SETPRV Miscellaneous. This is the implementation of the ANALYZE/DUMP command, and was the locus of one of the more serious VMS security bugs. I don't know why it needs such significant privileges. ANALIMDMP;1 Privileges = CMKRNL CMEXEC Not really privileged: LTPAD;3 Open Hdr Shar Privileges = TMPMBX MONITOR;3 Open Hdr Shar Privileges = TMPMBX NETMBX REQUEST;1 Privileges = TMPMBX RTPAD;1 Open Hdr Shar Privileges = TMPMBX SUBMIT;1 Open Hdr Shar Privileges = TMPMBX Ignoring the "not really privileged" class, we get 20 privileged images. Ignoring those that are really just parts of the kernel, we have 12 protected shareable images. Of the total of 32 "things" with privilege, 8 are part of DECWindows. I don't know how X is organized on a Unix system, but it cer- tainly has significant portions at least setuid, and often within the kernel. It would be interesting to see an analogous count of suid programs for a typical Unix system. I don't have any system handy to do this on... not that a count of images would mean much anyway. What matters is what the images *do*, who maintains them, and what kind of support the OS provides for getting them right. VMS comes out ahead on all these fronts, and especially on the last. Consider the protected images first. There are relatively few of these developed outside of the core OS team, and for good reason: It's quite difficult to build a secure protected image. The problem is that it's impossible for the protected image to rely on its caller in any way. It must truely implement a "system service", with full argument validation, full checking for necessary process privileges, etc. In the end, it must implement a service that can safely be called from any program - even if the interface is private, so that only known programs use it. While difficult, this keeps the parts of the code that have to be trusted to a minimum. Because MAILSHRP provides a safe interface to operations that it performs with privilege, any user can have access to the callable mail routines, with no special privileges - and neither those routines, nor the MAIL or MAIL_SERVER programs, are within the security perimeter of the system. Again, contrast this to the various setuid programs that make up a Unix mail system. Now consider programs installed with privilege. The VMS multi-privilege model helps considerably here. For example, a very common security hole allows someone to get a privileged program to read or write a file for them that they can't read or write themselves. Consider a program with even so powerful a privilege as CMKRNL - but without SYSPRV. This program will have no greater ability to open a file than the user who invokes it! Sure, it *could* open the file while in kernel mode - but it's unlikely to have any code to do that. It *could* set any privilege for itself that it wanted - but, again, it's unlikely to have code to do that either. So unless you can somehow modify the program's code significantly, fooling it into using the wrong file name isn't going to do you a bit of good. Some obvious examples of programs in this category are the system management applications. Constrast this to mainstream Unix, where an suid root program has access to everything on the system. There other similar examples. A common Unix security problem involves fooling a privileged program that accesses one of your files to follow a symbolic link to a file you shouldn't have access to. There are no symbolic links in VMS, but logical names play a similar role - except that privileged programs can, and do, ask RMS to use only inner-mode translations, which users without privileges can't create. Unix has setuid scripts - very handy, but a source of endless security problems. For many years, /etc/passwd was freely accessible, making off-line brute force or dictionary attacks on the hashed passwords feasible. (VMS closed this hole in V3.something.) Is VMS security perfect? Hardly. Does it do better than security on your typical Unix system - yes, by a significant amount. Whole classes of attacks that work against Unix systems will simply fail on VMS. -- Jerry