Bugzilla Bug 128690

Versions:     <= 1.8.6 (and current SVN 1.9.0)
Platforms:    Windows, *nix, *BSD, Mac and others
Bug:          format string bug in Con_Message and Con_Printf
Exploitation: remote, versus server and clients
Date:         03 Apr 2006
Author:       Luigi Auriemma
Source : full-disc


Bug (from full-disc) :


--- begin of quotation ---
The Doomsday engine contains many functions used for the visualization
of the messages in the console.
Both Con_Message and conPrintf are vulnerable to a format string
vulnerability which could allow an attacker to execute malicious code
versus the server or the clients.
The first function calls a "Con_Printf(buffer)" while the second one
calls a "SW_Printf(prbuff)" if SW_IsActive is enabled (which means
ever).

>From Src/con_main.c:

void Con_Message(const char *message, ...)
{
        va_list argptr;
        char   *buffer;

        if(message[0])
        {
                buffer = malloc(0x10000);

                va_start(argptr, message);
                vsprintf(buffer, message, argptr);
                va_end(argptr);

#ifdef UNIX
                if(!isDedicated)
                {
                        // These messages are supposed to be visible in the
real console.
                        fprintf(stderr, "%s", buffer);
                }
#endif

                // These messages are always dumped. If consoleDump is set,
                // Con_Printf() will dump the message for us.
                if(!consoleDump)
                        printf("%s", buffer);

                // Also print in the console.
                Con_Printf(buffer);

                free(buffer);
        }
        Con_DrawStartupScreen(true);
}

...

void conPrintf(int flags, const char *format, va_list args)
{
        unsigned int i;
        int     lbc;                            // line buffer cursor
        char   *prbuff, *lbuf = malloc(maxLineLen + 1);
        cbline_t *line;

        if(flags & CBLF_RULER)
        {
                Con_AddRuler();
                flags &= ~CBLF_RULER;
        }

        // Allocate a print buffer that will surely be enough (64Kb).
        // FIXME: No need to allocate on EVERY printf call!
        prbuff = malloc(65536);

        // Format the message to prbuff.
        vsprintf(prbuff, format, args);

        if(consoleDump)
                fprintf(outFile, "%s", prbuff);
        if(SW_IsActive())
                SW_Printf(prbuff);
    ...


--- end ---

no upstream update still available on
http://www.doomsdayhq.com/files.php?class=1

package masked

very fast!

masking-GLSA decision ?

poor gamers... :'(

If it's a B1 we should issue a masking GLSA.

OK. Jaervosz, i'm sure you wand to draft the GLSA :)

It's already in GLSAmaker :P

GLSA sent by DerCorny, thanks to everybody, sorry for the gamers.

The bug goes in enhancement, pending resolution.

Why wasn't this fixed prior to GLSA instead of masking this?
Judging by Luigi Auriemmas advisory the fix is trivial.
Is there more to this than described here?

Nobody is happy with a mask, but you should take into account that this game
doesnt seem to be supported by upstream anymore, so basically it was already
dead before this issue came up. Altough the fix might not be technically
challenging, it will take valuable time to implement and test it - do you
really think that we should waste our resources on dead things?

Created an attachment (id=84133) [edit]
Plug buffer overflows. Not even compile-tested.

How much people use it? I mean does it make sense to read through this junk
more carefully?

(In reply to comment #9)
> doesnt seem to be supported by upstream anymore, so basically it was already
> dead before this issue came up. Altough the fix might not be technically
> challenging, it will take valuable time to implement and test it - do you
> really think that we should waste our resources on dead things?

Yes, if the fix is obvious and no replacement exists.

No,
a) ..if the fix is too complicated/difficult and/or
b) ..a (brief) look at affected code sections
   shows that its too ugly/bug-ridden anyway.

IMO it would be a good idea to state the reason for masking
(Code looks suspicious; Unmaintained/Upstream dead, etc.) in future GLSAs.

As for "Upstream is dead": The last svn check in was (at this time of writing)
19 hours ago.... will try to contact them.

(In reply to comment #11)
> As for "Upstream is dead": The last svn check in was (at this time of writing)
> 19 hours ago.... will try to contact them. 

Fixed in svn. Don't know when a new release will be made, though.

Upstream for this is alive and well. You are aware that gentoo isn't even using
the current release right ? Current release is 1.9.0beta3, and that was
released a long time ago
http://prdownloads.sourceforge.net/deng/deng-1.9.0-beta3.tar.gz?download ,
Perhaps it would be an idea for a gentoo maintainer to keep in contact with
upstream (or other distro maintainers), or at the very least, follow progress
here http://deng.sourceforge.net/blog/.

Yeah, I'm happy to see that I was wrong about thinking that upstream is dead.
But betas are usually hardmasked, too - so this won't help a lot here.Games
team, upstream accepted a slightly edited version of the patch Alexey provided,
what do you think about patching and revbumping?

My personal option, (as the guy that has been preparing packages for ubuntu),
is that the bump to 1.9.0beta3 solves more bugs then it causes. The new memory
management system takes care of the most common, out of memory errors users
report.

Also, I'd like to thank you for doing a security audit on doomsday in the first
place.

1.9.0_beta3 now in portage

... which doesnt help as it doesnt contain the fix :)

can someone cut the patch from current svn for me to integrate please ?

It is known fixed as of svn 3153. Either backport changes, or wait for beta4.

We'll just wait.  Thanks.

beta4 is out.
http://sourceforge.net/project/showfiles.php?group_id=74815&package_id=75784&release_id=420613

Thanks Yagisan.

Games team , can you bump it please ?

Security team, please do what ever security stuff you need to do and reassign
to games for the version bump.  Thanks.

Games team, please bump or comment why not to do it.

Normal procedure is not to reassign but to cc maintainers/arches.

This is in progress...

A new ebuild has just been submitted into the tree.  You'll want the ppc team
to stabilize it.  I've stabilized it on x86.

great, let's go

ppc stable

Thanks to all. This one is ready for GLSA

sec team, i don't know yet how to handle final GLSAs after a temp GLSA. I let
you act here.

> sec team, i don't know yet how to handle final GLSAs after a temp GLSA. I let
> you act here.
> 

Jaervosz, Koon or DerCorny, or another security dev, please help us
drafting/sending a GLSA update for doomsday (or whatever is appropriate here).
Thanks in advance

jaervosz committed himself to do this .-)

I'll do it, hopefully in the evening.

(In reply to comment #32)
> I'll do it, hopefully in the evening.
> 

Sune, please, oh please... (and don't forget to delete the bogus doomsday entry
in glsamaker, thanks in advance)

Raphael, I've been too busy and forgot. Please prod me tonight and I'll fix it
(can't send from work).

/me pick up his coredump and stuffs it back in: We don't issue unmask GLSAs.
I've fixed it in GLSAmaker, Raphael could you review and I'll commit it.

Thanks Sune for the precision

############################################
Workaround:
There is no known workaround at this time.

There is no known workaround at this time.
############################################

Except that, it's ok.

I close that bug now

Thx Raphael for spotting that double boilerplate blunder. In CVS now.