Rust-sendmail, security vulnerabilities & how to handle it

community
1

Hello,
first of all: This has hunted me for quite some time, and I'm trying to get some input on this and also to give possible users a warning.
The sourcecode is quite short so you can look it up for yourself.

  • it is creating a file on disk with the email which should be send, with one function
  • the other function just calls bash and does something like sendmail < mail.txt

The problems I see with this are:

  • the library assumes it can read and write to the workspace path, if somebody isolates his application for any reason it'll crash
    This is unexpected/undocumented behavior of a sub library.
  • the file is stored on disk, so it can be read later on
  • the file is not deleted upon completion of the task, it will stay forever
  • it makes the library thread unsafe, as multiple calls to the lib would write to the same file (could this create any panics because of system locking?)
  • the library does not test for the permissions, it will just panic. There are not returns to indicate any IO errors, be it the file writing or the process call.

also

  • it depends on bash, which is another dependency

I've tried to fix this with a PR, it got merged (but changed a little bit without any comment, which I personally didn't like). To be fair I changed the library to use one function, as we don't need a text file and just push all over stdin pipes to the process of sendmail, basically replacing everything. Also I've added support for multiple recipients.
The PR got reverted without any further comment, which is the current state. Because of this I decided to write up a post.
I first wanted to wait till I have a better crate out, with a clean API and more support for options, then my current fork I use in production has. The recent reddit discussion on auditing crates created the urge to warn people and talk about this now.

The same author created also other mail sending crates, which behave in the same way, just calling another process than sendmail.

I am a little bit at loss, and would like to hear your feedback.

2

Perhaps explore https://crates.io/crates/lettre_email instead? I'm not sure what the preferred email crate is (if there is one), but this one appears to not use files to interact with sendmail (uses pipes instead). It also looks more polished than the sendmail crate, where the author(s) admit to being Rust beginners.

3

I will look into lettre, thanks. My problem is not a lack of better crates, I've submitted a PR which uses pipes and I'm still using that fork in my production code, as I've mentioned.

I've read that, but I would wish for more communication and expect an interest in improving. The whole thing just creates one big question-mark for me.

4

I can't speak to why the sendmail crate is the way it is, nor why your changes were rejected. But do note that anyone can publish any crate to crates.io and the onus is on you to be selective on which you decide to use. Unfortunately, this "crate quality" is a grey area right now, as is being discussed to some extent in a few parallel threads, incidentally.

1 Like
5

I guess that'll be a problem which you can't really solve.
I'm just a little bit sad about the lack of thought put into this. Most people here seem to put a great effort into their code, when they decide to release it into the public, which is what I'm missing here. ("how can this affect other people, is this good enough to release in this state or could it do more harm than help..")

Reagarding Lettre: Looks like I was looking too fast and was scared by its example. It show a tcp connection, when I wanted to use sendmail. It looks quite promising.

Edit: Also that code is from 2015, I would expect the author to gain a little bit more knowledge over time or take some of these issues more serious.