5 ms·

OpenSMTPD advisory dissected

45 points by Reventlov 7y ago

protomyth 7y ago
The "no mail to root" would be a major change. I generally put a .forward to a common sysadmin account, so I guess I would be curious their solution.
- asveikau 7y ago
  The recommendation I see in a lot of BSD guides and documentation is to use /etc/mail/aliases to make root's mail go somewhere else. Works slightly differently from ~/.forward
stefan_ 7y ago
It seems very simple for a MTA to be unprivileged: they can join us in the 21st century and drop the whole UNIX maildir, "login into the central terminal server with your UNIX account to read mail" thing. Write mail into a database or something, like every other goddamn service out there.
- clarry 7y ago
  Yes, just write it into a database or something, and rewrite the entire ecosystem to play nice with this new MTA that doesn't compose with existing tools. Wave hands until the problem solves itself somehow?
  - jcranmer 7y ago
    I mean, you'd have to design some sort of Mail Access Protocol to be able to get to this database, and then get everyone to be able to use that protocol. Surely that's impossible.
    - clarry 7y ago
      So now instead of privileged daemon forking MDAs to deliver everyone their mail, we have a database holding everyone's mail and everyone's connecting to that database, presumably through some daemon that can now access everyone's mail... maybe it doesn't run as root but I'm not convinced this improves the situation more than it shuffles the point of failure around (and arguably introduces more of such points).
      - viraptor 7y ago
        You already need a daemon which can access everyone's mail. Unless you're the only mail user on a server, whatever piece of the system logs you in, it dispatches the request to a given mailbox - it has to have global access by design. (even if indirectly by spawning another process with the right privileges) Disconnecting the concept of an email user from a system user definitely improves the situation and is unlikely to introduce new failure points. That's how the biggest email providers work - you don't expect gmail to create a new uid for you when you create an account, right?
      - jcranmer 7y ago
        I don't know what email service you use, but it's probably storing your email in a distributed database. An ancillary effect of using an actual database is that they generally play nicer with backups and actually making sure that you don't lose any data if the power goes out (doing this yourself is a recipe for disaster). Using a database doesn't require a privileged daemon, and the worst-case scenario (assuming a minimal threshold of competence) is that any attacker can only screw up the database in some way. With a privileged daemon, screwing up generally means that the attacker can potentially gain full control of your hardware, with all the nastiness that entails. Including, at a minimum, read your email or surreptitiously delete them.
        clarry 7y ago
        I host my own email. On assuming minimal threshold of competence.. you'd probably want to assume that nobody today plasters strings (while trying to escape the untrusted bits) to make SQL queries; many a database have been compromised this way. Here we are, looking at OpenSMTPD which did essentially the same: pass untrusted string to shell. Whoops. For anyone whose production email system were subject to such an issue, it's bad, really bad, whether it's an SQL query going against unprivileged database with all your data in it, or string going to root shell. I'm not terribly concerned about a piece of a daemon running as root. It's not the entire daemon, just a small privileged helper performing a tiny set of functions. I'd like to see it go, and I think it could go if we compromise on some features, change the way MDAs are invoked, or use a different permission model. The last one would probably be a relatively small change and allow existing tools to work (perhaps with small changes). I don't want to introduce a database and a daemon to store messages into it and another to let me read them. That's just adding more code, I want less code. I want a better security model, not shuffling responsibility away into a different daemon that needs to be maintained and audited and protected from a subtle big whoops.
    - e12e 7y ago
      I'm not sure if you're joking, but there are a couple of such protocols - IMAP being the most prominent. As for opensmtpd, it should probably only reject, drop or hand off mail via LMTP. Then another daemon should deal with storage and provide access to mail. You might look at dbmail.org if you want mail storage in PostgreSQL with IMAP support, for example. Dovecot can handle incoming mail via LMTP, but needs roit to write to mailboxes, unfortunately. I suppose you could give each user a suid binary to handle incommming email... Not sure if that'd be a great idea, though. Ed: ironically, a change along these lines resulted in this bug. Maybe it would be better if opensmtpd only spoke LMTP, and never did any launching of a shell. Conceivably the LMTP daemon might have a similar bug, though..
      - anonsivalley652 7y ago
        I wonder if instead of running a single mail delivery agent as root that can touch everything everywhere, a separate child process should run as that user and chroot/drop privs to where it can only write to mbox files and log if it can't. Or at least confine it to mbox files via SELinux, which still seems too open. Processes running as root for fs permissions reasons only is usually an ops smell that something wasn't architected or configured correctly.
        akira2501 7y ago
        I believe you're basically describing the architecture of qmail.
        anonsivalley652 7y ago
        Not even close. Qmail is quite different in that it uses maildirs instead of mbox and does a bunch of things differently including proprietary formats. And it's under-maintained and not widely used. I was only talking about the delivery of mail, not rearchitecting the world.
        edoceo 7y ago
        For mail, they also need low ports, which typically requires root.
  - anonsivalley652 7y ago
    Hey now, OpenSMTPD shouldn't be compared to systemd.
- deleted 7y ago
  [deleted]
- techntoke 7y ago
  Came here looking for every one to say just rewrite it in Rust like every other post, but surprisingly found someone who said just use a database for everything. Files are easier to backup, version and transparently encrypt. Try syncing a large database continuously with Google Drive, vs being able to sync new files. Files can be read by simply opening them in a text editor, just like email should. Email clients shouldn't have to connect to a database just to view your email. Linux solved authentication and permissions before MySQL.
  - jcranmer 7y ago
    A filesystem is nothing more than a database, albeit one that is usually very crappily implemented. For example, locking a file is a joke in POSIX. On Windows, locking a file will keep other processes from being able to read or write it, but POSIX will only keep other processes from being able to lock it. And it doesn't work on NFS anyways, so you have to use lock files in practice if you care about potentially working on NFS. This of course means that backing up files while running a process that might be using them is extremely dangerous--there's no guarantee that the backup system will capture the filesystem in a consistent state. A proper database will come with its own backup utility that is capable of backing up databases without taking them offline. > Linux solved authentication and permissions before MySQL. POSIX file permissions are a joke. You get to define just three levels of permissions (user, group, and everybody), and they apply coarsely to an entire file. Database permissions can define permissions for multiple users or sets of users, and some of them will even let you specify permissions on a per-record basis. I've worked with email clients, so I know how they're implemented, and how the protocols work, and how (some) servers work. Email needs to be stored in a database; it's what users expect in their UX; it's what protocol implementations require. Building that database on top of a file system might have been best practice in 1990, but it's 2020 now, and we know that filesystem-based databases are a disaster waiting to happen, so you'd be an idiot to do so today.
    - techntoke 7y ago
      > A filesystem is nothing more than a database, albeit one that is usually very crappily implemented. Then why do you still need a file system for your database files? Windows registry is a good example of how storing configurations in a database is a bad idea. > For example, locking a file is a joke in POSIX. I don't even see how that applies here, but you are talking about a bunch of different software vs a single database client used for a single purpose. There are mandatory locks if enabled and other solutions, but generally this isn't a problem unless you have unknown software accessing the same data as your program. > A proper database will come with its own backup utility that is capable of backing up databases without taking them offline. A file that is being written to hasn't been saved, therefore I would expect to only get a snapshot of the previous version. I don't see how that again applies to emails, often saved as individual files. > POSIX file permissions are a joke. You get to define just three levels of permissions (user, group, and everybody), and they apply coarsely to an entire file. There are ACLs. > Email needs to be stored in a database No it doesn't. It is best to cache metadata, but email has traditionally not been saved in a database and there are lot of benefits of saving emails as files that can be read from the file system. It is much easier to copy and sync files that store relevant information, than to take continuous versioned backups of a database that stores gigabytes of data.
deleted 7y ago
[deleted]
upofadown 7y ago
This seems pretty classic: * Five years ago a change causes a logic bug in a not super critical section of code. * Three and a half years later a change in an entirely different section of code makes the section of code super critical at the same time it makes it exploitable. Bugs can happen in any of the places you are not looking without actually changing anything in those places. Your code is full of trip mines and you don't know where any of the wires are.
boring_twenties 7y ago
The real question is why the fuck does mail delivery need to happen as root in the first place? On OpenBSD, mailboxes are mode 600. So, only root can write to them. On Debian with exim4, they are mode 660 -- writable by group "mail." So the MDA only needs to run as group mail, not user root. Is there some reason why OpenBSD is not doing the same thing?

45 points by Reventlov 7y ago

The "no mail to root" would be a major change. I generally put a .forward to a common sysadmin account, so I guess I would be curious their solution.

asveikau 7y ago
The recommendation I see in a lot of BSD guides and documentation is to use /etc/mail/aliases to make root's mail go somewhere else. Works slightly differently from ~/.forward

stefan_ 7y ago

It seems very simple for a MTA to be unprivileged: they can join us in the 21st century and drop the whole UNIX maildir, "login into the central terminal server with your UNIX account to read mail" thing. Write mail into a database or something, like every other goddamn service out there.

clarry 7y ago
Yes, just write it into a database or something, and rewrite the entire ecosystem to play nice with this new MTA that doesn't compose with existing tools. Wave hands until the problem solves itself somehow?
- jcranmer 7y ago
  I mean, you'd have to design some sort of Mail Access Protocol to be able to get to this database, and then get everyone to be able to use that protocol. Surely that's impossible.
  - clarry 7y ago
    So now instead of privileged daemon forking MDAs to deliver everyone their mail, we have a database holding everyone's mail and everyone's connecting to that database, presumably through some daemon that can now access everyone's mail... maybe it doesn't run as root but I'm not convinced this improves the situation more than it shuffles the point of failure around (and arguably introduces more of such points).
    - viraptor 7y ago
      You already need a daemon which can access everyone's mail. Unless you're the only mail user on a server, whatever piece of the system logs you in, it dispatches the request to a given mailbox - it has to have global access by design. (even if indirectly by spawning another process with the right privileges) Disconnecting the concept of an email user from a system user definitely improves the situation and is unlikely to introduce new failure points. That's how the biggest email providers work - you don't expect gmail to create a new uid for you when you create an account, right?
    - jcranmer 7y ago
      I don't know what email service you use, but it's probably storing your email in a distributed database. An ancillary effect of using an actual database is that they generally play nicer with backups and actually making sure that you don't lose any data if the power goes out (doing this yourself is a recipe for disaster). Using a database doesn't require a privileged daemon, and the worst-case scenario (assuming a minimal threshold of competence) is that any attacker can only screw up the database in some way. With a privileged daemon, screwing up generally means that the attacker can potentially gain full control of your hardware, with all the nastiness that entails. Including, at a minimum, read your email or surreptitiously delete them.
      - clarry 7y ago
        I host my own email. On assuming minimal threshold of competence.. you'd probably want to assume that nobody today plasters strings (while trying to escape the untrusted bits) to make SQL queries; many a database have been compromised this way. Here we are, looking at OpenSMTPD which did essentially the same: pass untrusted string to shell. Whoops. For anyone whose production email system were subject to such an issue, it's bad, really bad, whether it's an SQL query going against unprivileged database with all your data in it, or string going to root shell. I'm not terribly concerned about a piece of a daemon running as root. It's not the entire daemon, just a small privileged helper performing a tiny set of functions. I'd like to see it go, and I think it could go if we compromise on some features, change the way MDAs are invoked, or use a different permission model. The last one would probably be a relatively small change and allow existing tools to work (perhaps with small changes). I don't want to introduce a database and a daemon to store messages into it and another to let me read them. That's just adding more code, I want less code. I want a better security model, not shuffling responsibility away into a different daemon that needs to be maintained and audited and protected from a subtle big whoops.
  - e12e 7y ago
    I'm not sure if you're joking, but there are a couple of such protocols - IMAP being the most prominent. As for opensmtpd, it should probably only reject, drop or hand off mail via LMTP. Then another daemon should deal with storage and provide access to mail. You might look at dbmail.org if you want mail storage in PostgreSQL with IMAP support, for example. Dovecot can handle incoming mail via LMTP, but needs roit to write to mailboxes, unfortunately. I suppose you could give each user a suid binary to handle incommming email... Not sure if that'd be a great idea, though. Ed: ironically, a change along these lines resulted in this bug. Maybe it would be better if opensmtpd only spoke LMTP, and never did any launching of a shell. Conceivably the LMTP daemon might have a similar bug, though..
    - anonsivalley652 7y ago
      I wonder if instead of running a single mail delivery agent as root that can touch everything everywhere, a separate child process should run as that user and chroot/drop privs to where it can only write to mbox files and log if it can't. Or at least confine it to mbox files via SELinux, which still seems too open. Processes running as root for fs permissions reasons only is usually an ops smell that something wasn't architected or configured correctly.
      - akira2501 7y ago
        I believe you're basically describing the architecture of qmail.
        anonsivalley652 7y ago
        Not even close. Qmail is quite different in that it uses maildirs instead of mbox and does a bunch of things differently including proprietary formats. And it's under-maintained and not widely used. I was only talking about the delivery of mail, not rearchitecting the world.
      - edoceo 7y ago
        For mail, they also need low ports, which typically requires root.
- anonsivalley652 7y ago
  Hey now, OpenSMTPD shouldn't be compared to systemd.
deleted 7y ago
[deleted]
techntoke 7y ago
Came here looking for every one to say just rewrite it in Rust like every other post, but surprisingly found someone who said just use a database for everything. Files are easier to backup, version and transparently encrypt. Try syncing a large database continuously with Google Drive, vs being able to sync new files. Files can be read by simply opening them in a text editor, just like email should. Email clients shouldn't have to connect to a database just to view your email. Linux solved authentication and permissions before MySQL.
- jcranmer 7y ago
  A filesystem is nothing more than a database, albeit one that is usually very crappily implemented. For example, locking a file is a joke in POSIX. On Windows, locking a file will keep other processes from being able to read or write it, but POSIX will only keep other processes from being able to lock it. And it doesn't work on NFS anyways, so you have to use lock files in practice if you care about potentially working on NFS. This of course means that backing up files while running a process that might be using them is extremely dangerous--there's no guarantee that the backup system will capture the filesystem in a consistent state. A proper database will come with its own backup utility that is capable of backing up databases without taking them offline. > Linux solved authentication and permissions before MySQL. POSIX file permissions are a joke. You get to define just three levels of permissions (user, group, and everybody), and they apply coarsely to an entire file. Database permissions can define permissions for multiple users or sets of users, and some of them will even let you specify permissions on a per-record basis. I've worked with email clients, so I know how they're implemented, and how the protocols work, and how (some) servers work. Email needs to be stored in a database; it's what users expect in their UX; it's what protocol implementations require. Building that database on top of a file system might have been best practice in 1990, but it's 2020 now, and we know that filesystem-based databases are a disaster waiting to happen, so you'd be an idiot to do so today.
  - techntoke 7y ago
    > A filesystem is nothing more than a database, albeit one that is usually very crappily implemented. Then why do you still need a file system for your database files? Windows registry is a good example of how storing configurations in a database is a bad idea. > For example, locking a file is a joke in POSIX. I don't even see how that applies here, but you are talking about a bunch of different software vs a single database client used for a single purpose. There are mandatory locks if enabled and other solutions, but generally this isn't a problem unless you have unknown software accessing the same data as your program. > A proper database will come with its own backup utility that is capable of backing up databases without taking them offline. A file that is being written to hasn't been saved, therefore I would expect to only get a snapshot of the previous version. I don't see how that again applies to emails, often saved as individual files. > POSIX file permissions are a joke. You get to define just three levels of permissions (user, group, and everybody), and they apply coarsely to an entire file. There are ACLs. > Email needs to be stored in a database No it doesn't. It is best to cache metadata, but email has traditionally not been saved in a database and there are lot of benefits of saving emails as files that can be read from the file system. It is much easier to copy and sync files that store relevant information, than to take continuous versioned backups of a database that stores gigabytes of data.

deleted 7y ago

[deleted]

upofadown 7y ago

This seems pretty classic: * Five years ago a change causes a logic bug in a not super critical section of code. * Three and a half years later a change in an entirely different section of code makes the section of code super critical at the same time it makes it exploitable. Bugs can happen in any of the places you are not looking without actually changing anything in those places. Your code is full of trip mines and you don't know where any of the wires are.

boring_twenties 7y ago

The real question is why the fuck does mail delivery need to happen as root in the first place? On OpenBSD, mailboxes are mode 600. So, only root can write to them. On Debian with exim4, they are mode 660 -- writable by group "mail." So the MDA only needs to run as group mail, not user root. Is there some reason why OpenBSD is not doing the same thing?