Hello Jürgen,
Juergen Daubert <[email protected]> wrote:
|oss-sec reports several issues with BSD resp. Heirloom mailx:
|- http://seclists.org/oss-sec/2014/q4/1066
I've just seen it about 15 minutes ago.
|Are we affected as well?
1. We do support unlimited file and pipe addresses and as of now
there is no way to disable that. So if you say
$ echo boing | s-nail -Atmail -s "pipe test" '|cat > stdout.mbox'
$ echo boom | s-nail -Atmail -s "pipe test" ./stdout.mbox
then you should end up with a properly prepared stdout.mbox that
contains two messages. This is a documented feature.
The problem i now see is
- There is no way to turn it off.
The above report adds a *expandaddr* variable and turns that
off by default, which silently changes decade old behaviour.
Since NetBSD updated it's mailx(1) accordingly i'll follow
with S-nail so that the functionality doesn't diverse for
normal usage paths.
Note that i don't like that. Any software that blindly uses
user input from some web page or wherever else that contains
pipe or other shell meta characters is broken by design.
(It would be easier for everybody if POSIX would mandate
a vis(1/3), but this is something else.)
Unfortunately S-nail isn't yet at a point where we have
macros with return values etc., so that it can be really
batched -- i.e., it would be nice if you *could* pass *any*
input from a web page and let S-nail perform the necessary
checks (it is the mailer in the end), then react upon exit
status or (in batch mode) macro return value. This won't be
possible now. Like, say, giving the user two times an option
to enter garbage, then stall or linger to avoid DoS. Etc. :(
- These are simply honoured even in non-interactive mode, and
even without explicit requests to enable tilde escapes via -~
or -# command line options -- if you do so then mailx(1) will
offer several possibilities for shell access, via ~! or ~:sh,
to give some examples.
Since i have to add *expandaddr* anyway i'm sad, S-nail would
have had an option to disable those addresses unless -~ or -#
were given. I think for S-nail *expandaddr* (and that name)
will be ternary: off by default (not set), on (set empty) or
with value: in the latter case it will be off unless
interactive or -~ or -# were given.
2. The above report adds a "--" terminating command line argument
when calling the local MTA (in non SMTP-mode), in order to prevent
mail address with a leading hyphen to be interpreted as
system-wide aliases by the local MTA. Well. I have to check how
portable this is, but i'm a fan of being explicit.
On the other hand this can be accomplished for S-nail already
today by doing
$ echo bla | s-nail -Atmail -s "MTA 1" dubi@du -- --
or
$ echo bla | s-nail -Atmail -Ssendmail-arguments=" -- " -s "MTA 2" x@y
manually. Note the surrounding spaces are necessary. ;)
The latter version also allows adding more MTA arguments on the
command line, so i actually think i won't do something about that?
Maybe extend the documentation and add an example to the default
.rc file?
Hmm. How portable is this? Maybe 'set sendmail-arguments=" -- "'
should be made a default setting?
3. I think it was only OpenBSD who didn't support wordexp(3)
natively, but now does for a year or so, so we could make native
support for this mandatory. On the other hand i'd like to
continue support for old systems. (Again, vis(1/3) would make
it safe if wordexp(3) would be simulated via "$ echo STRING".)
I'll add the requested WRDE_NOCMD flag to the wordexp(3) call
(even though some implementations do or did not honour them. But
this is not our fault then. :)
4. I'm looking into this (Prevent command execution in the expand
function). Since i'm writing on this for more than thirty minutes
i think that is wiser. But i'm long trying to diverse expand()
into full expansion and a file-only one. Note we understand MIME,
so that parts of the linked problem don't affect us.
So whatever you want. Is this worth a subminor, given that
i planned to release v14.8 next week? I mean even -t requires
a prepared MBOX (!), it is not the -t from sendmail(1). On the
other hand i see the problem of not being able to turn off that
feature, and i admit that i haven't thought about the possibility
that plain data from web forms or something is used for
address-specifications "as-is".
What do you want, Jürgen? I can spend the day and implement
anything, place it on [master] and: prepare a patch, release
a subminor. Or wait some days and release v14.8 with the
necessary adjustments.
Just say a word. (I think i spend the day anyway.)
Ciao,
--steffen
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
S-nail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/s-nail-users
