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 attachment 84133 [details, diff] 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.
