When a message contains MIME attachments which are configured for plain-text display via the special `@' value for the according *pipe-CONTENT/SUBTYPE* variable then *if* the message is displayed so that headers of MIME attachments are shown on the display (as opposed to be `ignore'd a.k.a. not `retain'ed, i.e., for the `P'rint command which prints all headers by definition) then unfortunately a newly introduced bug will cause trouble (in configurations which HAVE_COLOUR): it will be tried to execute a command with a name equal to the last header field, e.g., `Content-Disposition:'.
The attached patch is also on [master]. I think false execution of rather random commands is well worth a subminor release (oh my god), given that an attacker may construct special vicious messages. Maybe i find some more time this week for this and that, i'll then release v14.7.6 on Friday or Saturday. Ciao, your unhappy --steffen
commit dee1fed (refs/remotes/origin/master, refs/heads/master) Author: Steffen (Daode) Nurpmeso <[email protected]> Date: 2014-08-11 21:38:29 +0200 send.c:_pipecmd(): fix [81473f8]: again ensure *result is set.. In [81473f8] (Add *pipe-EXTENSION*, ext. *mime-counter-evidence*.., 2014-07-11) i unfortunately broke the special `@' text handlers by no longer setting *result to NULL at function entry. The real cause of this bug however is the temporary colourization hack (i don't want to miss it again), since when i implemented the extended *mime-counter-evidence* stuff i reduced _pipecmd() to it's essence, the problem being that the local variable send.c:sendpart():pipecomm gets misused as temporary storage for the colourization -- due to this it is *not* NULL if _pipecmd() returns PIPE_TEXT to indicate forced treatment as text. I haven't yet seen this rather ultimate MCA because i do ignore all header fields (which come into play for MIME parts) for `p', and only display them for `P'. v14.8 will come with a test series. (sigh.) --- send.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/send.c b/send.c index bb710b0..12becab 100644 --- a/send.c +++ b/send.c @@ -533,20 +533,21 @@ _pipecmd(char **result, struct mimepart const *mpp) char *cp; NYD_ENTER; + *result = NULL; + /* Do we have any handler for this part? */ - if ((cp = mimepart_get_handler(mpp)) == NULL) { + if ((cp = mimepart_get_handler(mpp)) == NULL) ret = PIPE_NULL; - *result = NULL; - } /* User specified a command, inspect for special cases */ else if (cp[0] != '@') { /* Normal command line */ ret = PIPE_COMM; *result = cp; - } else if (*++cp == '\0') { + } + else if (*++cp == '\0') /* Treat as plain text */ ret = PIPE_TEXT; - } else if (!msglist_is_single) { + else if (!msglist_is_single) { /* Viewing multiple messages in one go, don't block system */ ret = PIPE_MSG; *result = UNCONST(_("[Directly address message only to display this]\n")); @@ -836,8 +837,12 @@ sendpart(struct message *zmp, struct mimepart *ip, FILE * volatile obuf, } } else { ignoring = 0; + /* For colourization we need the complete line, so save it */ + /* XXX This is all temporary (colour belongs into backend), so + * XXX use pipecomm as a temporary storage in the meanwhile */ #ifdef HAVE_COLOUR - pipecomm = savestrbuf(line, PTR2SIZE(cp2 - line)); + if (colour_table != NULL) + pipecomm = savestrbuf(line, PTR2SIZE(cp2 - line)); #endif } *cp2 = c; @@ -902,6 +907,7 @@ sendpart(struct message *zmp, struct mimepart *ip, FILE * volatile obuf, colour_reset(obuf); /* XXX reset after \n!! */ if (colour_stripped) fputc('\n', obuf); + pipecomm = NULL; } } #endif
------------------------------------------------------------------------------
_______________________________________________ S-nail-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/s-nail-users
