After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342111 - message format string vulnerability
message format string vulnerability
Product: dia
Classification: Other
Component: general
Other All
: Normal critical
: 0.95.1
Assigned To: Dia maintainers
Dia maintainers
Depends on:
Reported: 2006-05-17 11:38 UTC by Stanislav Brabec
Modified: 2006-05-27 13:03 UTC
See Also:
GNOME target: ---
GNOME version: ---

dia-message-format.patch (206 bytes, patch)
2006-05-17 11:39 UTC, Stanislav Brabec
none Details | Review
Patch fixing many format string vulnerabilities (8.97 KB, patch)
2006-05-23 07:57 UTC, Hans de Goede
none Details | Review
Patch fixing format string vulnerabilities (8.97 KB, patch)
2006-05-23 20:49 UTC, Hans de Goede
committed Details | Review

Description Stanislav Brabec 2006-05-17 11:38:01 UTC
Steps to reproduce:
1. touch
2. dia

The issue is public: and

Stack trace:

Other information:
I can confirm the problem, but I cannot confirm original report analysis:

vsprintf (buf, fmt, *args2) correctly returns:
 buf = (gchar *) 0xebb4a0 "Failed to load:\nImage file '%p%p%p%p.bmp' contains
no data"

The real problem seems to be message_create_dialog(), which provides the string
message_format to gtk_message_dialog_new(), which is defined as
GtkWidget*  gtk_message_dialog_new          (GtkWindow *parent,
                                             GtkDialogFlags flags,
                                             GtkMessageType type,
                                             GtkButtonsType buttons,
                                             const gchar *message_format,

Affected are all versions except the old ones using gtk_label_new()

I am not sure about correctness of alloc = nearest_pow (MAX(len + 1, 1024));
Maybe 1024 should be MAXPATHLEN.

And I don't know, why exactly there are two variables with the same varargs
contents - one is analysed to get the proper length, one is used for formatting.
Comment 1 Stanislav Brabec 2006-05-17 11:39:00 UTC
Created attachment 65665 [details] [review]

Proposed patch, which seems to fix the bug.
Comment 2 Hans de Goede 2006-05-20 12:05:04 UTC

I'm the Fedora dia package maintainer, as such I've taken a look into this. This is a classic format string vulnerability. At a first glance the fix seems correct and after carefull inspection the fix still seems correct.

As such I'm pushing new Fedora Extras packages with this fix included. Thanks Stanislav.

Comment 3 Alec Berryman 2006-05-20 12:31:06 UTC
This is CVE-2006-2480.
Comment 4 Hans de Goede 2006-05-23 07:57:32 UTC
Created attachment 66038 [details] [review]
Patch fixing many format string vulnerabilities

This has lead me to taking a closer look at the use of formatstrings in dia.

Yesterday I checked all the uses of:
dia's message* funcs

And reported my findings to John Bressers (from RedHat) and Stanislav Brabec <>. John has assigned CVE-2006-2453 for the additonal problems I found.

This morning I also checked (and found issues and fixed) all the uses of:

I've attached a patch fixing all issues I found. New as of this morning are the changes / fixes to:




There could still be other vararg printf like functions in dia which I didn't check. I'm in no way claiming this work is complete. With that said I'm not planning on doing any more auditing for printf like functions in dia in the near future.
Comment 5 Hans de Goede 2006-05-23 20:49:22 UTC
Created attachment 66086 [details] [review]
Patch fixing format string vulnerabilities

I was a bit short on time when I mailed my previous mail on this, so I
didn't test (I didn't even compile) the patch. It turns out my previous
patch contained one cut and paste error causing compilation to fail.

The attached patch fixes this and has been tested.

Also Stanislav Brabec <> has found one potential issue missed:

--- plug-ins/xfig/xfig-export.c
+++ plug-ins/xfig/xfig-export.c
@@ -263,7 +263,7 @@
 figWarn(XfigRenderer *renderer, int warning) 
   if (renderer->warnings[warning]) {
-    message_warning(renderer->warnings[warning]);
+    message_warning("%s", renderer->warnings[warning]);
     renderer->warnings[warning] = NULL;

Luckily this one isn't a security issue though. There is only one type of warning in the renderer->warnings array and this always gets initialised to: _("No more user-definable colors - using black") and is never changed, so this isn't a problem. Still I missed it :|

Notice that it still might be a good idea to fix this too  and that the attached patch doesn't fix this (The above diff does).
Comment 6 Lars Clausen 2006-05-26 19:51:32 UTC
Patch applied, thank you for your investigation!
Comment 7 Hans Breuer 2006-05-27 13:03:44 UTC
Also applied to HEAD:

2006-05-27  Hans Breuer  <>

	* app/app_procs.c app/display.c app/filedlg.c app/interface.c
	  app/load_save.c app/sheets.c lib/dia_image.c lib/message.c
	  plug-ins/python/diamodule.c plug-ins/python/pydia-error.c
	  plug-ins/wmf/wmf.cpp : fixed format string vulnerability on HEAD
	as well. Patch from Hans de Goede, bug #342111