Re: Error in debian package dia

2006-05-26 Thread Roland Stigge
Hi,

thanks for your report.

Sedlak Anton wrote:
 Your dia-common_0.94.0-7sarge3_all.deb
 has error in data.tar.gz (bad crc) for very long time - more then month.
 
 Due that this file is each day mirrored again and again.

Unfortunately, I can't do much about this directly. The security team
who created the file is informed for some time now and will probably
react when it is due.

Roland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: [Pkg-dia-team] Bug#368202: dia: CVE-2006-2480: format string vulnerability

2006-05-20 Thread Roland Stigge
Hi,

thanks for reporting this.

Alec Berryman wrote:
 CVE-2006-2480: Format string vulnerability in Dia 0.94 allows
 user-complicit attackers to cause a denial of service (crash) and
 possibly execute arbitrary code via format string specifiers in a .bmp
 filename. NOTE: since the exploit occurs through a command line
 argument, it is possible that this is not a vulnerability, unless there
 exist typical mechanisms under which the filename is automatically
 provided to Dia via another product, such as a browser.
 
 This is GNOME Bugzilla #342111 [1]; there is a proposed patch [2]
 attached to that entry.  Although the CVE mentions only version 0.94,
 Debian's 0.95.0-3 is vulnerable, and I am able to reproduce the issue
 with the instructions in Bugzilla.  With the patch applied, Dia no
 longer crashes but gives a can't open message.

Unfortunately, I can't reproduce this in full length. I can see the
error message popup (which I consider natural), but neither dia crashing
nor executing the malicious code (printing DIA).

I would like to have more info about that issue and maybe reproduction
help before pushing the patch (which actually seems to make the code at
least more graceful) to Debian stable.

I probably won't have network access during the next week, so
debian-security, feel free to upload the bugzilla.gnome.org patch to
stable if it turns out to be really necessary.

Thanks.

bye,
  Roland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



[Fwd: [Pkg-dia-team] Bug#364293: dia-common_0.94.0-7sarge3_all.deb is corrupted/incomplete?]

2006-04-22 Thread Roland Stigge
Hi,

indeed:

$ tar tfz data.tar.gz
[...]
./usr/share/omf/
./usr/share/omf/dia/
./usr/share/applications/
./usr/share/mime-info/
./usr/share/mime-info/dia.mime
./usr/share/mime-info/dia.keys
./usr/share/pixmaps/
./usr/share/pixmaps/dia_gnome_icon.png
./usr/share/pixmaps/dia-diagram.png
./usr/share/pixmaps/dia.xpm
./usr/share/pixmaps/dia_menu.xpm
./usr/share/doc-base/
./usr/share/doc-base/dia-manual
./usr/share/doc/dia-common/html/C

gzip: stdin: invalid compressed data--crc error
tar: Child returned status 1
tar: Error exit delayed from previous errors

Broken build environment on mipsel?

bye,
  Roland
---BeginMessage---
Package: dia-common
Version: 0.94.0-7sarge3
Tags: sarge

First, debsums reported a checksum mismatch in dia-common on
/usr/share/doc/dia-common/changelog.gz . Indeed, the end of the file looks like
garbage from a corrupted or incomplete gzip stream. I tried downloading another
copy of dia-common_0.94.0-7sarge3_all.deb manually, verified its md5sum against
the one stated in the distribution file (which matched, so it's not a download
problem), and indeed it looks like the archive is incomplete:

% md5sum dia-common_0.94.0-7sarge3_all.deb
00c9a9808842eaef293bdd0d15b40105  dia-common_0.94.0-7sarge3_all.deb
% grep -B 2 00c9a9808842eaef293bdd0d15b40105 /var/lib/dpkg/available
Filename: pool/main/d/dia/dia-common_0.94.0-7sarge3_all.deb
Size: 2149752
MD5sum: 00c9a9808842eaef293bdd0d15b40105
% ar x dia-common_0.94.0-7sarge3_all.deb
% tar -zxf dia-common_0.94.0-7sarge3_all.deb

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error exit delayed from previous errors
%

I guess the package should be built and uploaded again...

-- 
/  Patrick (L.) Bernier GPG DSA key fingerprint: /(
)))/   [EMAIL PROTECTED], [EMAIL PROTECTED]CB65 9634 BAB0 0122 86B1/((
))/http://www.TZoNE.ORG/~pat/   5AD5 9970 4BDA 66DC 1B23   /(((
)/ Words have meaning, and names have power. -- Lorien  /


___
Pkg-dia-team mailing list
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/pkg-dia-team
---End Message---


Re: [Pkg-dia-team] Bug#330890: dia: Arbitrary code execution when importing a .svg file

2005-09-30 Thread Roland Stigge
tag 330890 security
tag 330890 upstream
forwarded 330890 http://bugzilla.gnome.org/show_bug.cgi?id=317637
# woody:
notfound 330890 0.88.1-3
# sarge:
found 330890 0.94.0-7
# testing/unstable:
found 330890 0.94.0-14
# experimental
found 330890 0.94.0+CVS20050917-2
thanks

Hi,

thanks for reporting this issue.

Joxean Koret wrote:
 The script diasvg_import.py that comes with the current Debian stable
 version of Dia is vulnerable to an arbitrary code execution.
 
 I tried to contact with the Dia team too many times but without any look
 so, I think, there is no patch at the moment for the issues.

I couldn't find your comment on the upstream mailing list or in a GNOME
mozilla bug.

 Attached goes a working exploit to test the vulnerability.

Attached goes a fix that directly applies to the stable, testing and
unstable versions of dia in Debian (the respective code doesn't appear
in woody). Tested. Will coordinate with debian-security before uploading
to make fixes to stable and unstable consistent.

bye,
  Roland
Index: plug-ins/python/diasvg_import.py
===
--- plug-ins/python/diasvg_import.py	(revision 7)
+++ plug-ins/python/diasvg_import.py	(working copy)
@@ -54,6 +54,10 @@
 		return (int(m.group(1)) / 255.0, int(m.group(2)) / 255.0, int(m.group(2)) / 255.0)
 	# any more ugly color definitions not compatible with pango_color_parse() ?
 	return string.strip(s)
+
+def eval_secure(s):
+	return string.translate(s, string.maketrans(\(), ___))
+
 class Object :
 	def __init__(self) :
 		self.props = {x : 0, y : 0, stroke : none}
@@ -65,7 +69,8 @@
 			sp2 = string.split(string.strip(s1), :)
 			if len(sp2) == 2 :
 try :
-	eval(self. + string.replace(sp2[0], -, _) + (\ + string.strip(sp2[1]) + \))
+	eval(self. + eval_secure(string.replace(sp2[0], -, _)) +
+		(\ + eval_secure(string.strip(sp2[1])) + \))
 except AttributeError :
 	self.props[sp2[0]] = string.strip(sp2[1])
 	def x(self, s) :
@@ -282,7 +287,7 @@
 	def CopyProps(self, dest) :
 		# to be used to inherit group props to childs _before_ they get their own
 		for p in self.props.keys() :
-			sf = dest. + string.replace(p, -, _) + (\ + str(self.props[p]) + \)
+			sf = dest. + eval_secure(string.replace(p, -, _)) + (\ + eval_secure(str(self.props[p])) + \)
 			try : # accessor first
 eval(sf)
 			except :
@@ -561,7 +566,7 @@
 o = Group()
 stack.append(o)
 			else :
-s = string.capitalize(name) + ()
+s = eval_secure(string.capitalize(name)) + ()
 try :
 	o = eval(s)
 except :
@@ -575,7 +580,7 @@
 ma = string.replace(a, -, _)
 # e.g. xlink:href - xlink__href
 ma = string.replace(ma, :, __)
-s = o. +  ma + (\ + attrs[a] + \)
+s = o. +  eval_secure(ma) + (\ + eval_secure(attrs[a]) + \)
 try :
 	eval(s)
 except AttributeError, msg :


xautolock activation behaviour

2004-04-01 Thread Roland Stigge
Hi,

a user provided a convenience patch[1] for xautolock[2] preventing
xautolock from starting its configured executible (e.g. xlock) when the
computer just woke up from sleep.

IMHO this would raise a security issue for people assuming xlock to be
started after wakeup, so I propose to reject the patch. Any opposition?

Thanks.

bye,
  Roland

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241213
[2] http://packages.debian.org/unstable/x11/xautolock



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



xautolock activation behaviour

2004-04-01 Thread Roland Stigge
Hi,

a user provided a convenience patch[1] for xautolock[2] preventing
xautolock from starting its configured executible (e.g. xlock) when the
computer just woke up from sleep.

IMHO this would raise a security issue for people assuming xlock to be
started after wakeup, so I propose to reject the patch. Any opposition?

Thanks.

bye,
  Roland

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241213
[2] http://packages.debian.org/unstable/x11/xautolock