Bug#328458: heartbeat-1.2.3-9sarge4 for 3.1r1
Steve Feehan wrote: On Wed, Sep 28, 2005 at 03:34:22PM +0900, Horms wrote: Hi Martin, I have prepared packages that include this fix, from upstream, and no other changes, and you can find them at http://packages.vergenet.net/sarge-proposed-updates/heartbeat/ Steve, can you please verify that these packages resolve your problem. Yes, these packages work for me. Thank you very much! Ok, please upload. Regards, Joey -- Unix is user friendly ... It's just picky about its friends. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321927: Ubuntu patch for unzip CAN-2005-2475 (fwd)
Santiago Vila wrote: Christian, I received this patch from Ubuntu, so if I'm not mistaken, there are now three different ways to fix this bug (two of them from discussions that were not cc:ed to the Debian BTS), but so far none of these patches have been blessed by upstream (i.e. you). Is this patch good enough for unix systems? Ideally, we would like to patch this soon, even if the patch is not completely portable to, say, MS-DOS systems. Indeed. Please let us know if upstream responds. If not, please the patch you'll use for the package in sid so that the update in sarge can use the same. Regards, Joey -- Never trust an operating system you don't have source for! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318420: Ubuntu patch for net-snmp CAN-2005-2177
Martin Pitt wrote: The bug description is quite vague, but I believe it aims at this bug: http://sourceforge.net/tracker/index.php?func=detailaid=1207023group_id=12694atid=112694 which is fixed in http://cvs.sourceforge.net/viewcvs.py/net-snmp/net-snmp/snmplib/snmp_api.c?r1=5.44.2.18r2=5.44.2.19diff_format=u (5.1 branch). The vuln is already fixed in Sid, but Sarge is vulnerable. The Ubuntu patch which also applies to Sarge can be found at Thanks a lot, that bit was missing. Regards, Joey -- Never trust an operating system you don't have source for! Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
Florian Weimer wrote: As far as I understand it, from the perspective of the security team, it is not clear if the upstream change breaks existing user configurations. Users might rely on the current behavior and use it to deliberately weaken the filter policy. This is a reasonable question because the existing documentation is quite unclear about what MAC filters actually do. There are actually two behavioral changes we are talking about. The MACLIST_DISPOSITION=ACCEPT case is the easy one. If the user has activated this option, all hosts listed in the maclist configuration file are still filtered as desired. However, packets from any host whose MAC address is NOT listed there are accepted (and forwarded) by the firewall. (As far as I can see, this is not what has been described before, but I've checked that this is really the case.) This means that this behavior is virtually useless, and it is extremely unlikely that anyone uses it deliberately. The other case is MACLIST_TTL=nnn. This is a bit more complicated because the effect is restricted to hosts listet in maclist only. These hosts can bypass the remaining filter rules, so this might actually be useful in some scenarios, although it completely bypasses shorewall's zone concept. However, the MACLIST_TTL=nnn setting is documented as a performance optimization only (The performance of configurations with a large numbers of entries in /etc/shorewall/maclist can be improved by setting the MACLIST_TTL variable.). Despite the ambiguity of the documentation, this makes it rather unlikely that users have discovered this behavior and use it deliberately to implement their filtering policy. I've also skimmed the shorewall-users mailing list, but couldn't find a complaint that the firewall behavior changed in an unanticipated way after the security upgrade. So a summary would be to leave the package as it is in sarge, right? Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
Florian Weimer wrote: * Martin Schulze: So a summary would be to leave the package as it is in sarge, right? Based on the facts, I reach the opposite conclusion. The upstream changes should be merged. However, since easy workarounds are possible, we might get away without code changes, if issuing the update Lorenzo has prepared is too cumbersome for some reason. A DSA informing our users about the problem is necessary, even if no code changes take place. I'm surprised that there is any debate about this aspect. I thought that the question was if the upstream changes are too risky for an update to the stable distribution. Then apparently I was unable to parse your mail. Please try again. What was the behaviour pre-sarge? What is the behaviour post-sarge (or rather in sarge)? What do you think is the vulnerability? Why do you think there should be a DSA and what should it cover? Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
Florian Weimer wrote: * Martin Schulze: What was the behaviour pre-sarge? What is the behaviour post-sarge (or rather in sarge)? Do you mean before and after the upstream security update? The terms pre-sarge/post-sarge do not make much sense to me in this context, I'm afraid. Ok, so when did the behaviour change? Which behaviour is documented and hence expected? Which behaviour is experienced by potentially buggy code? What do you think is the vulnerability? The vulnerability is that the firewall fails to enforce the security policy the user has configured. That'd be a bug we should fix. Why do you think there should be a DSA and what should it cover? Here's a draft, in case you want to upload a fixed package. Thanks a lot, but I still have questions... (Note that I have yet to test Lorenzo's new package.) Are you in a position to do so? Supernaut noticed that shorewall could generate an iptables configuration which is significantly more permissive than the rule set given in the shorewall configuration. There are two issues, both related to the MAC verification configured in the maclist file. When MACLIST_DISPOSITION is set to ACCEPT in the shorewall.conf file, all packets from hosts which fail the MAC verification pass through the firewall, without further checks. Is this expected or based on the documentation? Or is the opposite documented? When MACLIST_TTL is set to a non-zero value, packets from hosts which pass the MAC verification pass through the firewall, again without further checks. Is this expected or based on the documentation? Or is the opposite documented? Regards, Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315957: Info
FWIW: I've just tried to install, reinstall and upgrade apache-ssl inside a sarge chroot environment and the package didn't show problem. So maybe this bug is indeed due to the many virtual hosts. Michael should debug the postinst script, e.g. by executing it with sh -x or by creative glancing over it to see what's going on. Regards, Joey -- There are lies, statistics and benchmarks. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310327: patch
Aníbal Monsalve Salazar wrote: Upon investigation of this problem I noticed that ssmtp (oldstable and stable) always strips the last line of the input before sending. gluck!joey(pts/4):~ seq 1 10|sendmail [EMAIL PROTECTED] -- 1..9 gluck!joey(pts/4):~ echo seq 1 10|sendmail [EMAIL PROTECTED] -- no lines This is not fixed by the above patch. I've patched ssmtp.c to fix the problem above and to close #310327 in ssmtp 2.61-5. It can be argued that you _must_ separate the data from the mail headers with an empty line. The following works: (echo; seq 1 10)|sendmail [EMAIL PROTECTED] If you want to really fix it, I can send you patches for the oldstable and stable versions of ssmtp. I can also prepare new packages as well. Please let me know what would you like me to do. Oh, I see. If I recall correctly, I've used mailx to build the mail before so that there was a header. Well, then it may not be a bug but a feature and we can leave it as it is. The other problem, the subject of #310327, is fixed in ssmtp 2.61-5 by the patch at: http://bugs.debian.org/cgi-bin/bugreport.cgi/ssmtp_2.61-4_non_blocking_fgets.diff?bug=310327;msg=64;att=2 That patch is not requiered for the versions of ssmtp currently in oldstable and stable as bug #310327 was introduced with ssmtp 2.61-3. Good news. Thanks. Regards, Joey -- All language designers are arrogant. Goes with the territory... -- Larry Wall Please always Cc to me when replying to me on the lists.
Bug#316590: woody backport now available for all cacti security issues
sean finney wrote: On Fri, Jul 15, 2005 at 04:15:22PM +0200, Martin Schulze wrote: However, as I don't like the next week part too much, I'll try to work on the update on my own and send you the diff for comments. Should reduce the time you need to spend on the issue as well. Ok, here is an update. i'll try and set some time aside tonight or tomorrow to test, but it looks good from an initial glance. Any outcome? In other words, any reason not to issue the advisory and update now? Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316590: woody backport now available for all cacti security issues
Sean Finney wrote: hi, On Mon, Jul 18, 2005 at 07:21:29PM +0200, Martin Schulze wrote: i'll try and set some time aside tonight or tomorrow to test, but it looks good from an initial glance. Any outcome? In other words, any reason not to issue the advisory and update now? i haven't had a chance to look at it yet, i've been busy packing up my personal life into boxes the past few days. i'm flying out to california today, and will have ample airport/airplane time with my laptop, so i should have something for you in the next 24 hours. i'll not only verify the patch works, but also see if there are any other variables that we missed which need to be dug up for sanity checking. Ok, I'll wait. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315671: webcalendar unauthorized access
Stephen Gran wrote: Hello all, Thanks a lot for contacting us. There is a security bug in webcalendar (#315671 and http://www.securityfocus.com/bid/14072, for reference). Tim is the maintainer, but does not yet have a debian account, and cannot upload. We have a fixed version for sarge ready (patch attached). I am happy to upload it for Tim, or you could based on the attached patch. Please let us know which way you want to handle this. Tim is copied on this mail, please keep both of us in the follow ups. There is as yet no CVE, but the bugtraq ID is 14072. I have requested an id. While we're at it, have you checked this vulnerability as well? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0474 I'll take care of sarge. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315703: Bug#316590: woody backport now available for all cacti security issues
Sean Finney wrote:
On Tue, Jul 19, 2005 at 07:54:31AM +0200, Martin Schulze wrote:
Ok, I'll wait.
so, a 6 hour plane flight later, i've learned 3 things:
1 - there are a number of other variables that also need to be included.
2 - there are a number of calls where variables are indirectly passed
to mysql_foo functions via other functions (which causes a problem
for the current sanity checking method)
3 - there is another, ridiculously obvious security vulnerability in
the woody version.
Thanks a lot for your investigation!
1 is easy to fix, we can just add on the extra variables to the file.
of the 900 or so calls to mysql_foo functions, i had about 170 left
to look at when my battery crapped out.
2 is trickier. we could either repeat the process i'm about finished
with wrt mysql_foo for all the functions that pass variables to
mysql_foo, or we could do the sanity checking in the function. as
the former sounds ugly and even more time consuming i'm going to
side with thte latter.
The less work and the less intrusive the patch the better.
what i think i'm going to do is split sanitize.php into sanitize and
sanitize-functions. sanitize will include_once sanitize-functions,
so then sanitize can be included multiple times (otherwise i believe
that php will bitch about functions being redefined), and i'll just
slip in a line in each mysql-calling function to include sanitize,
and add the variables in said functions to sanitize.php.
Sounds good.
as for 3, well... there's a variable, which is stored in a cookie.
the cookie name is cactilogin, and the value is an integer. want to
guess what it does? a fix for this shouldn't be too hard, this kind
of info should be stored in the session and not in the cookie.
Hmm, having the user id stored in a cookie is common practice.
The variable obviously needs to be sanitised as well.
anyway, i'll have a fair amount of free time tomorrow, but will need
a little sleep first :)
Ok. For reference I'm attaching the interdiff between the woody
version and the current updated version on security.debian.org (in
the private queue).
Regards,
Joey
--
Whenever you meet yourself you're in a time loop or in front of a mirror.
Please always Cc to me when replying to me on the lists.
diff -u cacti-0.6.7/include/config.php cacti-0.6.7/include/config.php
--- cacti-0.6.7/include/config.php
+++ cacti-0.6.7/include/config.php
@@ -23,6 +23,21 @@
*/?
?
+/* whether or not we pull from a db, we need re-initilize */
+global $config;
+
+/* test for suspicious user-supplied variables that would otherwise
+ affect program execution, and if so zero out config for safety */
+if(isset($_GET[do_not_read_config]) || isset($_POST[do_not_read_config])
+ || isset($_GET[config]) || isset($_POST[config])){
+$config = array();
+}
+$colors = array();
+
+## debian security backport ##
+require_once(sanitize.php);
+## debian security backport ##
+
## Debian packaging ##
include(/etc/cacti/config.php);
## Debian packaging ##
@@ -30,9 +45,6 @@
/* make sure this variable reflects your operating system type: 'unix' or
'win32' */
$cacti_server_os = unix;
-/* whether or not we pull from a db, we need re-initilize */
-global $config;
-
if ($do_not_read_config != true) {
if (isset($config) == false) {
/* make a connection to the database */
diff -u cacti-0.6.7/debian/changelog cacti-0.6.7/debian/changelog
--- cacti-0.6.7/debian/changelog
+++ cacti-0.6.7/debian/changelog
@@ -1,3 +1,25 @@
+cacti (0.6.7-2.4) oldstable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Switched to using $_REQUEST instead of $_GET and $_POST since this
+version only uses $foo which is similar to $_REQUEST[foo]
+ * Reduced the number of tested variables to those actually used.
+
+ -- Martin Schulze [EMAIL PROTECTED] Fri, 15 Jul 2005 16:06:58 +0200
+
+cacti (0.6.7-2.3) oldstable-security; urgency=high
+
+ * update prepared for the security team by new maintainer.
+ * include backported updates against the two latest cacti security
+releases. this includes the following CAN id's:
+- CAN-2005-1524 (idefense remote file inclusion)
+- CAN-2005-1525 (idefense SQL injection)
+- CAN-2005-1526 (idefense remote code execution)
+- CAN-2005-2148 (hardened-php advisories 032005 and 042005)
+- CAN-2005-2149 (hardened-php advisory 052005)
+
+ -- sean finney [EMAIL PROTECTED] Mon, 11 Jul 2005 20:35:12 -0400
+
cacti (0.6.7-2.2) stable-security; urgency=medium
* Non-maintainer upload by Stable Release Manager
only in patch2:
unchanged:
--- cacti-0.6.7.orig/include/sanitize.php
+++ cacti-0.6.7/include/sanitize.php
@@ -0,0 +1,123 @@
+?php
+
+/*
+ * backported security-related changes from cacti
+ * by sean finney [EMAIL PROTECTED]
+ *
+ * to preserve my own sanity, all sanity checks are done in here, which
+ * is included by the main configuration, which is included
Bug#315671: webcalendar unauthorized access
Stephen Gran wrote: Hello all, There is a security bug in webcalendar (#315671 and http://www.securityfocus.com/bid/14072, for reference). Tim is the maintainer, but does not yet have a debian account, and cannot upload. We have a fixed version for sarge ready (patch attached). I am happy to upload it for Tim, or you could based on the attached patch. Please let us know which way you want to handle this. Tim is copied on this mail, please keep both of us in the follow ups. There is as yet no CVE, but the bugtraq ID is 14072. Just got it: == Candidate: CAN-2005-2320 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2320 Reference: BID:14072 Reference: URL:http://www.securityfocus.com/bid/14072 WebCalendar before 1.0.0 does not properly restrict access to assistant_edit.php, which allows remote attackers to gain privileges. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316590: woody backport now available for all cacti security issues
Sean Finney wrote: this is done now. Thanks a lot. I have reviewed it and will use it for the advisory. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319406: heartbeat: upgrade and reconfigure errors
Horms wrote: The attached patch should resolve this problem, and I have put packages that include this patch up at http://debian.vergenet.net/pending/heartbeat/ Joey, what do you want to do about this? We can't do anything about it. All you can do, ant that's what you did already, is provide .deb files and add the link to this bug report. Fortunately, the problem does not occur regularily and does not affect many users (otherwise the bug would have been reported years ago already when there was a working proposed-updates directory). Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#110181: half-done
This is half-done. One can edit the CSS file (if one knows enough about CSS and stuff), but upon the next upgrade the changes would be gone since /usr/share/cvsweb/css/cvsweb.css is not a conffile. Hence, if you want to eventually fix and close this bug report, you'll have to move that file into /etc, install a link in /usr/share/cvsweb/css/ and mark the .css file as conffile. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322133: CAN-2005-2558: arbitrary binary libraries call execution
sean finney wrote: hi joey, martin, (christian may already be on vacation, so i'll try and field some responses from what i think is going on) [..] christian forwarded the bug information to mysql asking for a clarification (http://bugs.mysql.com/bug.php?id=12575) and we're waiting to hear back from them. Ok, thanks. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318463: Proposed update to e2fsprogs for stable
Steve Langasek wrote: On Sun, Aug 21, 2005 at 11:20:49PM -0400, Theodore Ts'o wrote: I would like to upload the following release to sarge to fix a grave bug (#318463), and taking the opportunity to fix a few other potential core-dumping inducing bugs. All of these are cherry picked from the e2fsprogs development tree. Should I go ahead and upload the following to stable-proposed updates? e2fsprogs (1.37-2sarge2) testing; urgency=low ^^^ If so, please be sure to fix the target in the changelog :) Even though this doesn't seem to be critical I'd accept it for the first stable update. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322352: pdns and pdns-doc both contain /usr/share/doc-base/pdns (sarge security update version)
Christoph Haas wrote: On Tue, Aug 16, 2005 at 12:06:48PM +0200, Jeremie Koenig wrote: I've not tested anything but I may have found the cause for this problem. Freshly extracted, the source package contains some cruft which gets removed upon running debian/rules clean. Specifically, [...] pdns-2.9.17/debian/doc-base pdns-2.9.17/debian/pdns-doc.postinst pdns-2.9.17/debian/pdns-doc.prerm pdns-2.9.17/debian/pdns.conffiles pdns-2.9.17/debian/pdns.postinst pdns-2.9.17/debian/pdns.postrm pdns-2.9.17/debian/pdns.prerm pdns-2.9.17/debian/shlibs.local Matthijs and I believe Jeremie could be right. In Joey's build logs it appears like the clean target hasn't been called during the build Correct. make build and make binary is called. process. We aren't happy that the upstream was shipping a debian/ directory along with the tarball and this might well be the cause that the build broke. I don't understand since the only directories in debian/ are: ./CVS ./po ./config ./patches ./manpage None of them looks like debian/tmp or debian/$packagename to me. As a fix we could re-create the upstream tarball with the debian/ directory removed from it. That should fix this issue. On the downside we would have to alter the orig file. Everyone's in favor? Not for sarge. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322352: pdns and pdns-doc both contain /usr/share/doc-base/pdns (sarge security update version)
Christoph Haas wrote: Check the upstream archive (pdns_2.9.17.orig.tar.gz) again: There are files like debian/doc-base that cause trouble. We are currently removing these files in the clean: target. But if that target isn't called before building the package we get this error. Ah, now I understand. In that case, it would be good to move # Clean up stuff in the debian directory rm -f debian/.cvsignore debian/CVS/Entries debian/CVS/Repository \ debian/CVS/Root debian/doc-base debian/pdns-doc.postinst \ debian/pdns-doc.prerm debian/pdns.conffiles debian/pdns.postinst \ debian/pdns.postrm debian/pdns.prerm debian/shlibs.local to the top of the build target. Since providing another orig archive is not an option we either need to build the package with the clean: target called first. Or move the cleanup part in the debian/rules makefile to another location that works better. Better move this line up and upload to stable, which will end up in proposed-updates (but will probably stall the package, unless the m68k and s390 buildds catch up). I just wonder why the clean: is run here on pbuilder and not on gluck. Because I use make and not pbuilder. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324652: nzb: Description is a non-description
Package: nzb Version: 0.1-1 Package: nzb Description: An nzb based Usenet binary grabber Mind writing a description? A real one, not such self-depending thing? Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319526: MySQL security bug in sarge (CAN-2005-1636)
Martin Schulze wrote: Christian Hammers wrote: Hello Security Team Are you aware of this bug? The interdiff patch are already in the BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319526 Applied the upstream patch that fixes a tempfile vulnerability in the mysqld_install_db script that was found by Eric Romang and allows an attacker to execute arbitrary SQL commands when the server is installed or updated. The issue is known as CAN-2005-1636, the patch was made by comparing this version against the one from 4.1.12. Thanks a lot for the update! I'll build packages, but will strip off the po file updates. Which package in unstable will fix this problem? Or is it not present in that distribution? Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324531: pcre3: patch for CAN-2005-2491
Martin Pitt wrote: Hi! Here is the relevant change from pcre3 6.1- 6.2, ported to 5.0: http://patches.ubuntu.com/patches/pcre3.CAN-2005-2491.diff Patch originally sent by Marcus Meissner from SuSE. Regards, Joey -- It's time to close the windows. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324531: PCRE3: CAN-2005-2491 for oldstable
Martin Pitt wrote:
Hi!
Since I have to fix apache2 2.0.50 for Ubuntu, which still has an
embedded pcre 3.x, I also took a look at the woody version. I took a
look at the code and played with the test suite, and it seems to me
that the capture part works ok; just the integer underflow must be
fixed:
--- pcre.c
+++ pcre.c
@@ -733,7 +733,7 @@
/* Do paranoid checks, then fill in the required variables, and pass back the
pointer to the terminating '}'. */
-if (min 65535 || max 65535)
+if (min 0 || min 65535 || max 0 || max 65535)
*errorptr = ERR5;
else
{
However, it would be nice to have a second pair of eyes to confirm
that this version is not vulnerable to the capturing overflow.
Confirmed. Named subpatterns are not available in the 3.* version,
so they don't need to be fixed.
Regards,
Joey
--
It's time to close the windows.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310327: patch
Aidas Kasparas wrote:
Please find bellow a patch which check EOF condition instead of no
input. Without fix for this bug package is virtually not useable (I
experienced mysterious attachment cuts, so I can not relay on it at it's
present form :-( Please consider importance of this bug as serious at
the very least.
--- ssmtp.c.R 2005-08-25 19:41:15.0 +0300
+++ ssmtp.c 2005-08-25 19:45:11.0 +0300
@@ -1532,7 +1532,13 @@
stdio functions like fgets in the first place */
fcntl(STDIN_FILENO,F_SETFL,O_NONBLOCK);
- while(fgets(buf, sizeof(buf), stdin)) {
+ while(!feof(stdin)) {
+ if (!fgets(buf, sizeof(buf), stdin)) {
+ /* if nothing was received, then no transmission
+* over smtp should be done */
+ sleep(1);
+ continue;
+ }
/* Trim off \n, double leading .'s */
standardise(buf);
- 8
Upon investigation of this problem I noticed that ssmtp (oldstable
and stable) always strips the last line of the input before sending.
gluck!joey(pts/4):~ seq 1 10|sendmail [EMAIL PROTECTED]
-- 1..9
gluck!joey(pts/4):~ echo seq 1 10|sendmail [EMAIL PROTECTED]
-- no lines
This is not fixed by the above patch.
Regards,
Joey
--
WARNING: Do not execute! This call violates patent DE10108564.
http://www.elug.de/projekte/patent-party/patente/DE10108564
wget -O patinfo-`date +%Y%m%d`.html http://patinfo.ffii.org/
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325254: kdegraphics packages broken on sarge/powerpc because of kdelibs4 dependency
Adeodato Simó wrote: severity 325254 serious reassign 325254 kdegraphics,security.debian.org retitle 325254 kdegraphics 3.3.2-2sarge1/powerpc uninstallable because of dependency on kdelibs4 (= 4:3.3.2-6.2) notfound 325254 4:3.3.2-2 found 325254 4:3.3.2-2sarge1 thanks * Jochen Antesberger [Fri, 26 Aug 2005 19:25:32 -0500]: Package: kdegraphics Version: 4:3.3.2-2 Severity: important *** Please type your report below this line *** The security updates for the kdegraphics packages for Sarge on powerpc cannot be installed because they depend on kdelibs4 = 4:3.3.2-6.2 while only = 4:3.3.2-6.1 is available. ARGS. An advisory for kdelibs is pending but missing the mips build. Why the )*(#%$ does a KDE package depend on the exact Debian version of another KDE package? That should not be the case in the first place. I suppose the correct kdelibs4 package needs to be supplied by the security servers as well to allow the new packages to be installed and the security gap being closed on the powerpc architecture. Will happen soon. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book Please always Cc to me when replying to me on the lists.
Bug#325135: maildrop: lockmail doesn't drop privileges
Max Vozeler wrote: Short description: lockmail.maildrop (setgid mail) lets the user specify a program and execvp()s it, but does not drop egid mail privilege before doing so. This opens a trivial privilege escalation (see poc) to group mail. Thanks a lot for the report. This is CAN-2005-2655. The bug affects 1.5.3-1.1 sarge/etch/sid and 1.8.1-2 in experimental, and should be easy to fix: Just add setgid(getgid()) before the execvp(). I tested the attached patch briefly and verified that it builds and prevents this bug. Steve, could you take care of sid and experimental packages if Joy is too busy? The bug appears to be specific to Debian, upstream doesn't seem to install lockmail with a setgid flag. Oh. Woody is not affected either. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325135: maildrop: lockmail doesn't drop privileges
Andres Salomon wrote: On Sat, 2005-08-27 at 11:42 +0100, Steve Kemp wrote: On Sat, Aug 27, 2005 at 12:27:51PM +0200, Martin Schulze wrote: Thanks a lot for the report. This is CAN-2005-2655. The bug affects 1.5.3-1.1 sarge/etch/sid and 1.8.1-2 in experimental, and should be easy to fix: Just add setgid(getgid()) before the execvp(). I tested the attached patch briefly and verified that it builds and prevents this bug. Steve, could you take care of sid and experimental packages if Joy is too busy? Certainly. Once the advisory is out I can make an upload if Joy hasn't already made one. I can also do an upload; Joy already said I should comaintain, I've just Please go ahead. been waiting for racke to do a new courier upload so that I can actually use maildrop (I have new maildrop packages in experimental that're just rotting away, waiting). Speaking of racke, has anyone checked whether courier-maildrop needs the same patch? Not before your mail. However, it seems that the code is in the source package, but there is no lockmail binary exposed by courier, hence, no need to patch it as well. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328275: www.debian.org: debian-faq seems outdated
Javier Fernández-Sanguino Peña wrote: The page on http://www.debian.org/doc/manuals/debian-faq/index.en.html says: version CVS, 14 February 2003. However, the current doc-debian package ships version 3.1.2, 9 June 2005. Is the debian-faq on the web really as outdated as it seems? If so, it'd be nice if someone could make sure it got updated. If not, it'd be cool if someone could fix the misleading version string. For some reason bot the english and all the translations are stalled in that date without there being any indication in the CVS log [1] or Make log [2] that something is amiss. I believe that a build needs to be forced in www-master, but I don't have access to klecker, as it's restricted. CCing [EMAIL PROTECTED] so that they do a 'make clean' in the /org/www.debian.org/www/doc/manuals/faq directory to see if this can be fixed. Oh, you should have seen something in the build log: make[1]: Leaving directory `/org/www.debian.org/ddp/manuals.sgml/faq/pl' make[1]: Entering directory `/org/www.debian.org/ddp/manuals.sgml/faq/es' make[1]: *** No rule to make target `debian-faq.sgml', needed by `debian-faq.es.html/index.es.html'. Stop. make[1]: Leaving directory `/org/www.debian.org/ddp/manuals.sgml/faq/es' make: *** [html] Error 2 Looks like an error to me. Since the build process is aborted by this, I guess that's why there was no new version on the web. Now there is none... Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists.
Bug#328275: www.debian.org: debian-faq seems outdated
Javier Fernández-Sanguino Peña wrote: On Wed, Sep 14, 2005 at 04:44:33PM +0200, Joost van Baal wrote: Package: www.debian.org Severity: normal Hi, The page on http://www.debian.org/doc/manuals/debian-faq/index.en.html says: version CVS, 14 February 2003. However, the current doc-debian package ships version 3.1.2, 9 June 2005. Is the debian-faq on the web really as outdated as it seems? If so, it'd be nice if someone could make sure it got updated. If not, it'd be cool if someone could fix the misleading version string. For some reason bot the english and all the translations are stalled in that date without there being any indication in the CVS log [1] or Make log [2] that something is amiss. I believe that a build needs to be forced in www-master, but I don't have access to klecker, as it's restricted. CCing [EMAIL PROTECTED] so that they do a 'make clean' in the /org/www.debian.org/www/doc/manuals/faq directory to see if this can be fixed. Does not exist, but I've removed the contents of the debian-faq directory and have started make in the build directory manually. Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists.
Bug#318946: User expectations and shorewall
Florian Weimer wrote: (Note that I have yet to test Lorenzo's new package.) Are you in a position to do so? Sure, but the question is if you want to rely on the results. You don't seem to trust my judgement on this matter, for reasons I don't know. I simply did not understand the problem. Hence, didn't understand the vulnerability. Hence, didn't understand what would need to be fixed. If you can, please build an updated package, based on the version in sarge and woody if that's needed as well, and place them on a .debian.org host. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318946: User expectations and shorewall
Lorenzo Martignoni wrote: If you can, please build an updated package, based on the version in sarge and woody if that's needed as well, and place them on a .debian.org host. I already have a fixed package. I only need to add the CVE ID. On which host of .debian.org should I upload it? If you've got an account on them, any fits, since I have an account on all of them. If you don't, just drop me the URLs. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328626: Sarge update for loop-aes-utils (CAN-2005-2876)
Max Vozeler wrote: Hi security team, the loop-aes-utils package in sarge is affected by CAN-2005-2876 (#328626). I've prepared a stable-security upload of 2.12p-4sarge1 with a fix backported from 2.12r-pre1: http://people.debian.org/~xam/security/loop-aes-utils/ This bug will be fixed in unstable with 2.12p-9 (pending upload). Thanks a lot. Note that this update will not be effective until mount is also fixed. The /bin/umount binary from 'mount' is diverted to /bin/umount.orig and remains setuid root, so an attacker could just use that binary instead of the one from loop-aes-utils. Yes, a fix for the original mount is pending already. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322352: [Powerdns-debian] Bug#322352: pdns and pdns-doc both contain /usr/share/doc-base/pdns (sarge security update version)
Matthijs Mohlmann wrote: Hi, Daniel Dickinson wrote: Package: pdns Version: 2.9.17-13sarge1 Severity: serious Justification: Policy 6.5.4 Both pdns-doc_2.9.17-13sarge1_all.deb and pdns_2.9.17-13sarge1_all.deb contain /usr/share/doc-base/pdns. This prevents whichever of these packages is second in the installation order from being installed. Plus it is a violation of Debian Policy 6.5.4 You are right, the bug exist in the current security release of sarge, but I don't know how it comes there. I've build it twice by myself and I couldn't find the bug. Please retry in the sarge chroot on gluck or escher. I've just rebuilt it in both environments and both times the pdns_*.deb contained both /usr/share/doc/pdns and /usr/share/doc-base/pdns, while the package in sarge does not. Looking at the file contents, it shouldn't be an architecture.deb but an all.deb, btw., but that's not an issue we need to fix now. Martin Schulze: How did you build the package ? (I'm pretty curious right now because I can't reproduce it) I could send you the build log, but since it can still be reproduced, just build it on your own. When you know the reason why, please come back to me so an update could go in via proposed-updates. Regards, Joey -- It's time to close the windows. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322352: pdns and pdns-doc both contain /usr/share/doc-base/pdns (sarge security update version)
Christoph Haas wrote: Hi, Martin... On Sat, Aug 13, 2005 at 07:09:02AM +0200, Martin Schulze wrote: Please retry in the sarge chroot on gluck or escher. I've just rebuilt it in both environments and both times the pdns_*.deb contained both /usr/share/doc/pdns and /usr/share/doc-base/pdns, while the package in sarge does not. I have just taken the diff file from http://security.debian.org/debian-security/pool/updates/main/p/pdns/pdns_2.9.17-13sarge1.diff.gz and created a package on gluck (dchroot sarge). This is the packages content: [EMAIL PROTECTED]:~/test$ dpkg -c pdns_2.9.17-13sarge1_i386.deb drwxr-xr-x0 2005-08-15 13:55:38 ./ drwxr-xr-x0 2005-08-15 13:55:35 ./usr/ drwxr-xr-x0 2005-08-15 13:55:35 ./usr/share/ drwxr-xr-x0 2005-08-15 13:55:35 ./usr/share/doc/ drwxr-xr-x0 2005-08-15 13:55:43 ./usr/share/doc/pdns/ -rw-r--r-- 9799 2004-09-13 19:34:03 ./usr/share/doc/pdns/changelog.gz -rw-r--r-- 353 2005-08-15 13:40:49 ./usr/share/doc/pdns/README.Debian -rw-r--r-- 928 2005-08-15 13:40:49 ./usr/share/doc/pdns/copyright -rw-r--r-- 3974 2005-08-15 13:40:49 ./usr/share/doc/pdns/changelog.Debian.gz So there is no /usr/share/doc-base/pdns in here. I admit that I built the package this morning and also found the 'doc-base' in the package. But not any more. I have no idea what I changed (there should be no two diff files like that) but using the diff file from the above URL everything went well. That is very strange. I've just rebuilt it on gluck (see /tmp/joey for log and packages) and it does still contain the doc-base directory. If we know what's going on, we can start fixing. Regards, Joey -- GNU GPL: The source will be with you... always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322352: pdns and pdns-doc both contain /usr/share/doc-base/pdns (sarge security update version)
Christoph Haas wrote: On Tue, Aug 16, 2005 at 10:23:41AM +0200, Martin Schulze wrote: That is very strange. I've just rebuilt it on gluck (see /tmp/joey for log and packages) and it does still contain the doc-base directory. I was too slow for /tmp/joey. :( Matthijs suspected that it might have to do with gluck being an SMP machine. Perhaps some kind of race condition? Shrug! If we want to fix it, we need to find out... Is there a general technical difference between dchroot sarge and a Sarge pbuilder? Yes. pbuilder builds the chroot from scratch, while dchroot uses the existing chroot environment on the particular host. (and don't require root permissions) Regards, Joey -- GNU GPL: The source will be with you... always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319526: MySQL security bug in sarge (CAN-2005-1636)
Christian Hammers wrote: Hello Security Team Are you aware of this bug? The interdiff patch are already in the BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319526 Applied the upstream patch that fixes a tempfile vulnerability in the mysqld_install_db script that was found by Eric Romang and allows an attacker to execute arbitrary SQL commands when the server is installed or updated. The issue is known as CAN-2005-1636, the patch was made by comparing this version against the one from 4.1.12. Thanks a lot for the update! I'll build packages, but will strip off the po file updates. Regards, Joey -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322825: Partial fix
Looks like the redesign of the BTS broke reportbug horribly since it
depends on a certain set of URLs and content. As both has been
altered, reportbug fails.
The fix for the --mbox failure is simple, and indeed attached to this
message.
The fix for the 'No report available' problem is more difficult since
the parser of the HTML version of the bug report needs to be adjusted
to work with the new HTML code. That looks like a lot more work.
Regards,
Joey
--
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum
Please always Cc to me when replying to me on the lists.
--- debianbts.py.orig 2005-08-19 20:31:20.0 +0200
+++ debianbts.py2005-08-19 20:51:07.0 +0200
@@ -375,7 +375,7 @@ def yn_bool(setting):
def cgi_report_url(system, number, archived=False, mbox=False):
root = SYSTEMS[system].get('cgiroot')
if root:
-return '%sbugreport.cgi?bug=%darchive=%smbox=%s' % (
+return '%sbugreport.cgi?bug=%darchive=%s;mbox=%s' % (
root, number, archived, yn_bool(mbox))
return None
Bug#316590: cacti security update, second version available fixing all issues
sean finney wrote: hi, i've prepared a new version which addresses both the previous issues addressed in sarge0 and the new hardened-php reported issues: deb http://people.debian.org/~seanius/cacti/sarge ./ deb-src http://people.debian.org/~seanius/cacti/sarge ./ version: 0.8.6c-7sarge2 note the sources have changed from the previous location. I have modified the version to reflect the needs for security a bit. Two more CVE ids have been assigned: == Candidate: CAN-2005-2148 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2148 Reference: MISC:http://www.hardened-php.net/advisory-032005.php Reference: MISC:http://www.hardened-php.net/advisory-042005.php Reference: MLIST:[cacti-announce] 20050701 Cacti 0.8.6f Released Reference: URL:http://sourceforge.net/mailarchive/forum.php?forum_id=10360max_rows=25style=flatviewmonth=200507viewday=1 Reference: CONFIRM:http://www.cacti.net/downloads/patches/0.8.6e/cacti-0.8.6f_security.patch Cacti 0.8.6e and earlier does not perform proper input validation to protect against common attacks, which allows remote attackers to execute arbitrary commands or SQL by sending a legitimate value in a POST request or cookie, then specifying the attack string in the URL, which causes the get_request_var function to return the wrong value in the $_REQUEST variable, which is cleansed while the original malicious $_GET value remains unmodified, as demonstrated in (1) graph_image.php and (2) graph.php. == Candidate: CAN-2005-2149 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2149 Reference: MISC:http://www.hardened-php.net/advisory-052005.php Reference: MLIST:[cacti-announce] 20050701 Cacti 0.8.6f Released Reference: URL:http://sourceforge.net/mailarchive/forum.php?forum_id=10360max_rows=25style=flatviewmonth=200507viewday=1 Reference: CONFIRM:http://www.cacti.net/downloads/patches/0.8.6e/cacti-0.8.6f_security.patch config.php in Cacti 0.8.6e and earlier allows remote attackers to set to modify session information to gain privileges and disable the use of addslashes to protect against SQL injection by setting the no_http_headers switch. Please mention them in the sid package as well when you're doing the next upload. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea. signature.asc Description: Digital signature
Bug#248600: Contents file for woody does not contain non-US anymore
Adam D. Barratt wrote: On Thu, 2004-05-13 at 10:17 +0200, Martin Schulze wrote: [...] James Troup wrote: Martin Schulze [EMAIL PROTECTED] writes: [...] It seems that the Contents-$arch.gz file for woody does not contain non-US anymore. It never did? [...] Well, if it never did, it's a wishlist bug at most... Given that non-US has now been obsoleted, is it reasonable to assume that this will never be implemented? Correct, I'd say, but it's not me to decide. Regards, Joey -- Computers are not intelligent. They only think they are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309739: woody is still vulnerable to CAN-2005-1544
Jay Berkenbilt wrote: Some time ago, a bug was posted about tiff being vulnerable to CAN-2005-1544: a bug that caused and exploitable segmentation fault on files with certain bad BitsPerSample values (making it a potential DOS bug). The fix is already in sarge. I had posted a patch against the version of the package in Woody some time ago, but I had not tested it. I have now built and tested this in a woody environment, and I believe that it does resolve the problem. The attached patch is identical to the other one except that it also patches debian/changelog. Feel free to disregard that part and treat this a security NMU. The portion of the patch that updates tif_dirread.c should be fine. Bug 309739 is still open (tagged woody). My patch to the changelog closes it. If this gets uploaded in some other way, someone can manually close the bug. Please let me know if there's anything else I need to do with this. Thanks! Hmm, I must hav missed your earlier mail somehow. I haven't even stored a trace of this issue. I'm pushing it into the buildd network now. Thanks a lot. Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305142: CAN-2005-2214: insegure apt-setup
severity 305142 important tags 305142 security thanks Is there any motion on this problem? == Candidate: CAN-2005-2214 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2214 Final-Decision: Interim-Decision: Modified: Proposed: Assigned: 20050712 Category: SF Reference: MISC:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305142 Reference: SECUNIA:15955 Reference: URL:http://secunia.com/advisories/15955 apt-setup in Debian GNU/Linux installs the apt.conf file with insecure permissions, which allows local users to obtain sensitive information such as passwords. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#44910: gnupg: should not leasen permissions
Thijs Kinkhorst wrote: On Tue, July 12, 2005 12:33, Werner Koch wrote: On Tue, 12 Jul 2005 10:37:41 +0200, Thijs Kinkhorst said: version of GnuPG in Debian (1.4.1-1). I'm wondering what the stance of upstream is on this bug: will or won't it be fixed? I don't see the problem with this. In same cases we could create a file with the same permissions as the source file but not in all. Often gpg does not work on the file but just reads the content. This common Unix behaviour (cf. cat(1)). If there are concerns, make sure the umask has ben set properly. Sor signing confidential files, a detached signature is anyway a better choice. Another reason not to change it is that it changes the interface and thus would break myriads of scripts. Thanks for your reply, if the original submitter (Joey) agrees, then I propose to close this bug. Err... since it's easy to call isatty() on the input stream to find out if there's an inode associated, I'd rather keep the bug report and add the wontfix tag. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315703: woody backport now available for all cacti security issues
sean finney wrote: another update, the security release for cacti has been delayed due to complications backporting the security fix into the version in woody, which is a major release (and rewrite) behind the versions in sarge and sid. joey from the security team provided an initial attempt at backporting the backport to woody, but unfortunately it was not sufficient to completely address the vulnerability. it also did not include fixes for the second set of vulnerabilities released by the hardened-php project. having spent more time hacking on it than i'd have liked, i've now produced a new version of the backport, which i believe should address all of the relevant security issues. it can be found at the following uris: deb http://people.debian.org/~seanius/cacti/woody ./ deb-src http://people.debian.org/~seanius/cacti/woody ./ all this said, i think it should be strongly emphasized that upstream is no longer supporting the woody version of cacti and does not provide updates for it, and users should be advised to upgrade to at least the version in sarge ASAP. i'm also not convinced that there aren't other security issues in the woody version, but can at least feel reasonably comfortable that of the recently published vulnerabilities woody's cacti should be okay with this new revision. joey, mike, et al: is there anything else you need from me? I guess we're facing a severe problem here. Even though you say that my fixes were not sufficient, you have ***removed*** a fair amount of the patches I've applied after reading the code that uses unsanitised variables. I now see that you've placed sanitising into the config file entirely, would have been nice to note this. Additionally you seem to be using get_request_var only which uses the $_GET array, but not the $_REQUEST array, and hence can be bypassed by POST or cookie input if I am not mistaken. This was not the case in the version I sent you. In addition to that you also clutter sanitize.php with sanitising variables that aren't even used. That's not ok. Regards, Joey PS: ... and the distribution needs to be set to oldstable-security -- Reading is a lost art nowadays. -- Michael Weber Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315703: woody backport now available for all cacti security issues
Sean Finney wrote: i guess i didn't in the email updating this, but did so in sanitize.php itself: Yes, I saw that later. I hope, my tone wasn't too harsh. Additionally you seem to be using get_request_var only which uses the $_GET array, but not the $_REQUEST array, and hence can be bypassed by POST or cookie input if I am not mistaken. This was not the case in the version I sent you. the problem with using _REQUEST is that someone could provide a valid _POST variable, but sneak the malcious content into _GET, which would then pass a _REQUEST test (assuming order gpc), but if the system uses _GET it still uses the malicious content. this is most of the cause of the second set of advisorires. Yes, but the woody version does not use $_GET *anywhere* except in the alleged sanitising code you included. It uses $foo instead of $_GET[foo] all the time, which means for me - if I'm not mistaken - that we should use either $foo or $_REQUEST[foo] in the sanitising code. however, now that i think about it, since i think most variables in the woody version of cacti are using register_globals, a variable like $id will be set in the same order as $_REQUEST, so maybe that isn't a bad idea. True. now that i think about it even more, what would be best is to run the sanity check on all of the _GET, _POST, _COOKIE variables, and fail if any of them have bad values. that would make the patch even simpler. It seems to me that running them on $_REQUEST only is sufficient. Or do you know of a possibility that $foo can include something which is not in $_REQUEST when inserted via GET/POST/cookie/$whatever? In addition to that you also clutter sanitize.php with sanitising variables that aren't even used. That's not ok. aren't even used on a specific page or aren't used at all in cacti? in Aren't used at all. See this for example: finlandia!joey(pts/15):/src/debian/security/work/cacti/cacti-0.6.7 find -type f|xargs grep cdef_id ./include/sanitize.php:input_validate_input_number(get_request_var(cdef_id)); finlandia!joey(pts/15):/src/debian/security/work/cacti/cacti-0.6.7 The only use of $cdef_id is in the sanitising code. For such cases we don't need sanitising. the case of the former, it causes no problems (apart from a couple extra cycles, which i think is OK in the interest of a cleaner patch). in the I already accepted that the correction due to its size will be done centralised and hence not on each page. okay. so this is what i will do in the next week: - modify sanitize.php to check all three _FOO arrays for bad values and quit out if any of them are bad. I'd go for _REQUEST only. - double check sanitize.php for globally unused variables. - update the distribution name. how does that sound? Good. However, as I don't like the next week part too much, I'll try to work on the update on my own and send you the diff for comments. Should reduce the time you need to spend on the issue as well. Regards, Joey -- Computers are not intelligent. They only think they are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316590: woody backport now available for all cacti security issues
Martin Schulze wrote:
However, as I don't like the next week part too much, I'll try to
work on the update on my own and send you the diff for comments.
Should reduce the time you need to spend on the issue as well.
Ok, here is an update.
Regards,
Joey
--
Computers are not intelligent. They only think they are.
Please always Cc to me when replying to me on the lists.
diff -u cacti-0.6.7/include/config.php cacti-0.6.7/include/config.php
--- cacti-0.6.7/include/config.php
+++ cacti-0.6.7/include/config.php
@@ -23,6 +23,21 @@
*/?
?
+/* whether or not we pull from a db, we need re-initilize */
+global $config;
+
+/* test for suspicious user-supplied variables that would otherwise
+ affect program execution, and if so zero out config for safety */
+if(isset($_GET[do_not_read_config]) || isset($_POST[do_not_read_config])
+ || isset($_GET[config]) || isset($_POST[config])){
+$config = array();
+}
+$colors = array();
+
+## debian security backport ##
+require_once(sanitize.php);
+## debian security backport ##
+
## Debian packaging ##
include(/etc/cacti/config.php);
## Debian packaging ##
@@ -30,9 +45,6 @@
/* make sure this variable reflects your operating system type: 'unix' or
'win32' */
$cacti_server_os = unix;
-/* whether or not we pull from a db, we need re-initilize */
-global $config;
-
if ($do_not_read_config != true) {
if (isset($config) == false) {
/* make a connection to the database */
diff -u cacti-0.6.7/debian/changelog cacti-0.6.7/debian/changelog
--- cacti-0.6.7/debian/changelog
+++ cacti-0.6.7/debian/changelog
@@ -1,3 +1,25 @@
+cacti (0.6.7-2.4) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Switched to using $_REQUEST instead of $_GET and $_POST since this
+version only uses $foo which is similar to $_REQUEST[foo]
+ * Reduced the number of tested variables to those actually used.
+
+ -- Martin Schulze [EMAIL PROTECTED] Fri, 15 Jul 2005 16:06:58 +0200
+
+cacti (0.6.7-2.3) stable-security; urgency=high
+
+ * update prepared for the security team by new maintainer.
+ * include backported updates against the two latest cacti security
+releases. this includes the following CAN id's:
+- CAN-2005-1524 (idefense remote file inclusion)
+- CAN-2005-1525 (idefense SQL injection)
+- CAN-2005-1526 (idefense remote code execution)
+- CAN-2005-2148 (hardened-php advisories 032005 and 042005)
+- CAN-2005-2149 (hardened-php advisory 052005)
+
+ -- sean finney [EMAIL PROTECTED] Mon, 11 Jul 2005 20:35:12 -0400
+
cacti (0.6.7-2.2) stable-security; urgency=medium
* Non-maintainer upload by Stable Release Manager
only in patch2:
unchanged:
--- cacti-0.6.7.orig/include/sanitize.php
+++ cacti-0.6.7/include/sanitize.php
@@ -0,0 +1,123 @@
+?php
+
+/*
+ * backported security-related changes from cacti
+ * by sean finney [EMAIL PROTECTED]
+ *
+ * to preserve my own sanity, all sanity checks are done in here, which
+ * is included by the main configuration, which is included by everything.
+ * variables that don't exist will not raise failures, so only in the case
+ * that the input exists and is not what it is supposed to be will there
+ * be an error.
+ */
+
+/*
+ +-+
+ | Copyright (C) 2004 Ian Berry|
+ | |
+ | This program is free software; you can redistribute it and/or |
+ | modify it under the terms of the GNU General Public License |
+ | as published by the Free Software Foundation; either version 2 |
+ | of the License, or (at your option) any later version. |
+ | |
+ | This program is distributed in the hope that it will be useful, |
+ | but WITHOUT ANY WARRANTY; without even the implied warranty of |
+ | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
+ | GNU General Public License for more details.|
+ +-+
+ | cacti: a php-based graphing solution|
+ +-+
+ | Most of this code has been designed, written and is maintained by |
+ | Ian Berry. See about.php for specific developer credit. Any questions |
+ | or comments regarding this code should be directed to: |
+ | - [EMAIL PROTECTED] |
+ +-+
+ | - raXnet - http://www.raxnet.net
Bug#294890: Typo in wait(2): watpid
tags 294890 pending thanks Michael Kerrisk wrote: This bug is by now fixed upstream (fixed in man-pages-2.03). Please close this bug. Only after I've uploaded the new package, will do so after LinuxTag. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483667: newmail: typo in the package description
Arnaud Guiton wrote: There is a typo in the package description: the name of the program is misspelled ! :-) It contains The nemail program usually... when it should obviously be The newmail program usually Well spotted, fixed with a new upload. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479896: sysklogd: fails to stop on reboot/shutdown
Petter Reinholdtsen wrote: [Martin Schulze] Petter, you can probably tell why insserv has trouble shutting down syslogd. Yes. It does not really have problems shutting down syslogd. The issue here is that I should have made it depend on $remote_fs instead of $local_fs, because with the current setup it need to stop before sendsigs kills it. The init.d script for sysklogd and klogd have a bug that make it report failure when stopping the daemon also when the daemon is already stopped. This is what is happing here. init.d/sendsigs already killed both, and later when the sysklogd and klogd scripts are executed during shutdown, they complain. The quick fix is to change the dependency information like this: diff -u /etc/init.d/sysklogd /tmp/sysklogd --- /etc/init.d/sysklogd2008-02-23 20:20:01.0 +0100 +++ /tmp/sysklogd 2008-05-08 21:42:35.0 +0200 @@ -3,8 +3,8 @@ ### BEGIN INIT INFO # Provides: sysklogd -# Required-Start: $local_fs $time -# Required-Stop:$local_fs $time +# Required-Start: $remote_fs $time +# Required-Stop:$remote_fs $time # Should-Start: $network # Should-Stop: $network # Default-Start:2 3 4 5 Thanks. I would also recommend changing klogd like this to make sure it can be installed with any syslog daemon, not only sysklogd. diff -u /etc/init.d/klogd /tmp/klogd --- /etc/init.d/klogd 2008-02-23 20:20:08.0 +0100 +++ /tmp/klogd 2008-05-08 21:42:25.0 +0200 @@ -3,8 +3,8 @@ ### BEGIN INIT INFO # Provides: klogd -# Required-Start: sysklogd -# Required-Stop:sysklogd +# Required-Start: $syslog +# Required-Stop:$syslog Where is $syslog defined? Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479896: sysklogd: fails to stop on reboot/shutdown
Petter Reinholdtsen wrote: [Martin Schulze] Where is $syslog defined? $syslog is a virtual facility defined in the LSB, and for the purpose of dependency based boot sequencing in Debian, it is defined in /etc/insserv.conf. See URL:http://wiki.debian.org/LSBInitScripts for the list of virtual facilities. Thanks. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481873: pre-inst should mkdir
Package: dokuwiki Version: 0.0.20080505-1 Hi, it would be nice if the pre-installation script would check whether $conf['savedir'] . '/../tmp' exists and create that directory with proper permissions prior to the upgrade to this new upstream version. That would actually help existing wikis to continue working after the upgrade. There's also something broken with UCF, the upgrade is stalled until I hit Enter about half a dozen times. Thanks, Joey -- Never trust an operating system you don't have source for! Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460904: more infos
The fix should be implemented in the function imap_sync_mailbox() in imap.c. Instead of deleting all mail at once the list of UIDs should be limited to a certain size. Cyrus 2.1 doesn't like it to be larger than 8k for example, for Cyrus 2.2 the limit seems to be at 16k I've heard. Implementing a loop in this function will probably require the function imap_make_msg_set() to take another argument so that it can stop after a certain size is reached. The IMAP commands for removing mails are UID STORE list of uids EXPUNGE Regards, Joey -- Never trust an operating system you don't have source for! Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489355: Installation warnings
Lucas Nussbaum wrote: On 05/07/08 at 10:44 +0200, Joey Schulze wrote: Package: ruby1.8-elisp Version: 1.8.7.22-2 Severity: wishlist Hi Joey, Several bugs have been reported against the ruby1.*-elisp packages. Unfortunately, none of the ruby maintainers are using emacs, and this emacs mode is unmaintained upstream, AFAIK. If you have time to work on those issues, or can find someone to work on them, it would be very much appreciated. From looking at the changelog, this package seems to be maintained by Daigo Moriwaki [EMAIL PROTECTED]. Isn't this the case? Regards, Joey -- Linux - the choice of a GNU generation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489355: Installation warnings
Lucas Nussbaum wrote: On 07/07/08 at 09:33 +0200, Martin Schulze wrote: Lucas Nussbaum wrote: On 05/07/08 at 10:44 +0200, Joey Schulze wrote: Package: ruby1.8-elisp Version: 1.8.7.22-2 Severity: wishlist Hi Joey, Several bugs have been reported against the ruby1.*-elisp packages. Unfortunately, none of the ruby maintainers are using emacs, and this emacs mode is unmaintained upstream, AFAIK. If you have time to work on those issues, or can find someone to work on them, it would be very much appreciated. From looking at the changelog, this package seems to be maintained by Daigo Moriwaki [EMAIL PROTECTED]. Isn't this the case? The Debian package is part of the ruby1.8 source package. One could argue that shipping an emacs mode with a scripting language interpreter isn't really a good idea. And yes, Daigo is one of the co-maintainers for the ruby1.8 source package. Oh, I see. I thought it was a package of its own. Hadn't checked before. I assume that upstream is not taking care of the Emacs mode either? Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489355: Installation warnings
Lucas Nussbaum wrote: Last time I contacted them about the bugs that are filed in Debian on the emacs mode, I got no answer. Then I don't think I'd be the one. Feel free to contact me for testing the mode wrt. particular fixes or problems, though. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485990: ascii(7): Apostroph is accent in UTF-8 environment
Jörg Sommer wrote:
Package: manpages
Version: 2.80-1
Severity: normal
Hi,
% LC_ALL=C man ascii G 047 | awk '{print $4;}' | hexdump
000 270a
^^
% LC_ALL=de_DE.UTF-8 man ascii G 047 | awk '{print $4;}' | hexdump
000 c2b4 0a00
I think you must tell roff that you really mean the character 0x27.
Arjan Opmeer wrote:
Looking at the man page I see that the escaped version of some characters
are used.
\e for \ (which won't work when the escape character is redefined)
\_ for _ what is that non-printable, zero width character doing there?
\` for ` but the escaped version maps to the grave accent
\' for ' but the escaped version maps to the acute accent
\- for - why? we want the real minus character, not some hyphen
As UTF8 and all the ISO-8859-x fonts have the standard ASCII character set
at the beginning, why not use the real ASCII characters in this man page?
After all, it is about the ASCII set now how you could pretty format that on
some output device.
I have to admit that I'm lost here.
Regards,
Joey
--
Whenever you meet yourself you're in a time loop or in front of a mirror.
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488605: manpages is trying to overwrite `/usr/share/man/man7/hostname.7.gz'
Dario Minnucci (midget) wrote: Package: manpages Version: 3.00-1 Severity: normal Cannot upgrade version 3.00-1 with 3.01-1. Here is the log [...] Preparing to replace manpages 3.00-1 (using .../manpages_3.01-1_all.deb) ... Unpacking replacement manpages ... dpkg: error processing /var/cache/apt/archives/manpages_3.01-1_all.deb (--unpack): trying to overwrite `/usr/share/man/man7/hostname.7.gz', which is also in package bind There is no package 'bind' (anymore) in sid. It is superseded by bind9 which would have removed it. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488605: manpages is trying to overwrite `/usr/share/man/man7/hostname.7.gz'
Michael, this is a Debian-specific problem, nothing you could solve (except by removing hostname.7 again). Michael Kerrisk wrote: On Mon, Jun 30, 2008 at 3:42 AM, Dario Minnucci (midget) [EMAIL PROTECTED] wrote: Package: manpages Version: 3.00-1 Severity: normal Cannot upgrade version 3.00-1 with 3.01-1. Here is the log [...] Preparing to replace manpages 3.00-1 (using .../manpages_3.01-1_all.deb) ... Unpacking replacement manpages ... dpkg: error processing /var/cache/apt/archives/manpages_3.01-1_all.deb (--unpack): trying to overwrite `/usr/share/man/man7/hostname.7.gz', which is also in package bind dpkg-deb: subprocess paste killed by signal (Broken pipe) Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/manpages_3.01-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Hi Dario, I added hostname.7 in upstream man-pages-3.01. What package does the other hostname.7 come from, do you know? That's hidden in the message above: trying to overwrite `/usr/share/man/man7/hostname.7.gz', which is also in package bind However, that package shouldn't be installed on Dario's machine at all as it has been superseded by 'bind9'. Unfortunately it seems to me that the's a transitional package missing that'll cause it to be removed. Thus, I believe the bug is in the package bind9/bind and not in manpages. However, I could fix this by conflicting/replacing bind with manpages. Before doing so I'll first see what LaMont (bind9 maintainer) thinks about it. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487173: mention syslogd-listfiles in some SEE ALSO
[EMAIL PROTECTED] wrote: Package: sysklogd Version: 1.5-4 Severity: wishlist File: /usr/share/man/man8/syslogd.8.gz On at least syslogd(8) mention SEE ALSO syslogd-listfiles(8), else it seems it is an orphan man page. There is no real connection from syslogd(8) to syslogd-listfiles(8). Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479896: sysklogd: fails to stop on reboot/shutdown
Andrei Popescu wrote: Package: sysklogd Version: 1.5-2 Severity: normal Hello, On shutdown I get: Stopping system log daemon ... failed and later umount: /var: device is busy umount2: Device or resource busy umount: /var: device is busy failed (these are from what I could write down during the shutdown, could be minor differences). I am using insserv, but I can't tell if it started before or after its activation. Petter, you can probably tell why insserv has trouble shutting down syslogd. Regards, Joey -- Never trust an operating system you don't have source for! Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473458: manpages-dev: dlopen man page contradicts ld.so(8)
Martin Schulze wrote: I stand corrected, I cannot fix this. The version of ld.so.8 comes from the libc6 package and not from the manpages package as one might assume. As the package has been reassigned already nothing needs to be done on my end I guess. For the record: On rPath Linux, OWL and Alt Linux ld.so.8 comes from the man-pages package. Regards, Joey -- In the beginning was the word, and the word was content-type: text/plain Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363394: Broken description
Package: shishi Looking at the following descriptions: lia href=http://packages.debian.org/unstable/net/shisa;shisa/a -- Administration utilitity for Shishid./li lia href=http://packages.debian.org/unstable/net/shishi;shishi/a -- Command line utilitity for Shishi./li lia href=http://packages.debian.org/unstable/libs/shishi-common;shishi-common/a -- Platform independent files for the Shishi library./li lia href=http://packages.debian.org/unstable/libdevel/shishi-dbg;shishi-dbg/a -- Debugging symbols for Shishi./li lia href=http://packages.debian.org/unstable/doc/shishi-doc;shishi-doc/a -- Documentation for Shishi./li lia href=http://packages.debian.org/unstable/net/shishid;shishid/a -- Key Distribution Center (KDC) server daemon for Shishi./li I see the following description dependency graph: +-+ | | shisa - shishid - shishi -+ ^ ^ ^ | | | shishi-common | shishi-dbg | shishi-doc So not even the description of the package most descriptions depend upon is self-contained but depends on itself. Even though recursion is nice, it does not have to be implemented in package descriptions. Please untie and release the descriptions Regards, Joey -- GNU GPL: The source will be with you... always. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363392: shisa: Description kaputt
Package: shisa Version: current Severity: minor Description: Administration utilitity for Shishid ^ What is that? (shishid shouldn't be capitalised either, I'd say) Regards, Joey -- GNU GPL: The source will be with you... always. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363394: Broken description
Simon Josefsson wrote: Martin Schulze [EMAIL PROTECTED] writes: Package: shishi Looking at the following descriptions: lia href=http://packages.debian.org/unstable/net/shisa;shisa/a -- Administration utilitity for Shishid./li This is now: -- Administration utility for the Shishi KDC database lia href=http://packages.debian.org/unstable/net/shishi;shishi/a -- Command line utilitity for Shishi./li lia href=http://packages.debian.org/unstable/libs/shishi-common;shishi-common/a -- Platform independent files for the Shishi library./li lia href=http://packages.debian.org/unstable/libdevel/shishi-dbg;shishi-dbg/a -- Debugging symbols for Shishi./li lia href=http://packages.debian.org/unstable/doc/shishi-doc;shishi-doc/a -- Documentation for Shishi./li lia href=http://packages.debian.org/unstable/net/shishid;shishid/a -- Key Distribution Center (KDC) server daemon for Shishi./li I see the following description dependency graph: +-+ | | shisa - shishid - shishi -+ ^ ^ ^ | | | shishi-common | shishi-dbg | shishi-doc So not even the description of the package most descriptions depend upon is self-contained but depends on itself. Even though recursion is nice, it does not have to be implemented in package descriptions. Please untie and release the descriptions Hi again. I'm not sure I understand what the problem is. The problem is that you have created recursive description dependencies that don't explain what the packages do or contain if somebody doesn't know already what 'Shishi' is. Hence, they should be changed. What about shishid -- Shishi Key Distribution Center - server daemon shishi -- Command line client for Shishi Key Distribution Center Or something on that line. Regards, Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359332: boinc-client: Description improvement
Frank S. Thomas wrote: package boinc-client tags 359332 + pending thanks Moin Joey, On Monday 27 March 2006 23:33, Martin Schulze wrote: lia href=http://packages.debian.org/unstable/net/boinc-client;boinc-client/a -- BOINC core client./li lia href=http://packages.debian.org/unstable/devel/boinc-dev;boinc-dev/a -- BOINC platform for distributed computing (development files)./li lia href=http://packages.debian.org/unstable/x11/boinc-manager;boinc-manager /a -- control and monitor utility for the BOINC core client./li So what the heck is a BOINC core client? Please describe the package and don't simply repeat the name of the package. We changed the short descriptions to: -Description: BOINC core client +Description: core client for the BOINC distributed computing infrastructure -Description: control and monitor utility for the BOINC core client +Description: GUI to control and monitor the BOINC core client -Description: BOINC platform for distributed computing (development files) +Description: development files to build applications for BOINC projects That's much better Regards, Joey -- Computers are not intelligent. They only think they are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352620: confirmed
I can confirm this problem, also based on a different base locale: Generating locales (this might take a while)... de_DE.ISO-8859-1.../usr/share/i18n/locales/iso14651_t1:264: LC_COLLATE: syntax error /usr/share/i18n/locales/iso14651_t1:266: LC_COLLATE: syntax error [..] [then the process hangs] finlandia!joey(tty6):~/Projects/freeX/Perl-12.smtp apt-cache show locales Package: locales [..] Version: 2.3.6-1 [..] Depends: glibc-2.3.5-3, debconf | debconf-2.0 [..] finlandia!joey(tty6):~/Projects/freeX/Perl-12.smtp dpkg -s libc6 Package: libc6 [..] Version: 2.3.5-6.0.1 [..] Provides: glibc-2.3.5-3 [..] I can also confirm that the problem goes away with glibc 2.3.6-1*. So there's at least a wrong dependency in the locales package. Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350964: CVE-2006-0225, scponly shell command possible
Thomas Wana wrote: Hi, Geoff Crompton wrote: This bug has been closed for unstable (see bug 350964) with the 4.6 upload, but will it be fixed for sarge? Joey: I sent you a patch for that, but it seems you didn't include this in scponly-4.0sarge1. We also had no discussion about wether to include it or not. Please clarify. Which patch. Plese clarify. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291380: [msutton@iDefense.com: iDEFENSE Security Advisory 01.19.05: MySQL MaxDB Web Agent Multiple Denial of Service Vulnerabilities]
Package: maxdb Severity: grave Tags: sarge security # sid is already fixed, so this is a reminder. Two CVE ids have been assigned to this advisory: Candidate: CAN-2005-0081 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0081 Reference: IDEFENSE:20050119 MySQL MaxDB Web Agent Multiple Denial of Service Vulnerabilities Reference: URL:http://www.idefense.com/application/poi/display?id=187type=vulnerabilities MySQL MaxDB 7.5.0.0, and other versions before 7.5.0.21, allows remote attackers to cause a denial of service (crash) via an HTTP request with invalid headers. Candidate: CAN-2005-0082 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0082 Reference: IDEFENSE:20050119 MySQL MaxDB Web Agent Multiple Denial of Service Vulnerabilities Reference: URL:http://www.idefense.com/application/poi/display?id=187type=vulnerabilities The sapdbwa_GetUserData function in MySQL MaxDB 7.5.0.0, and other versions before 7.5.0.21, allows remote attackers to cause a denial of service (crash) via invalid parameters to the WebDAV handler code, which triggers a null dereference that causes the SAP DB Web Agent to crash. Please mention them in the changelog (or add them to the changelog later with your next upload). Regards, Joey - Forwarded message from Michael Sutton [EMAIL PROTECTED] - Subject: iDEFENSE Security Advisory 01.19.05: MySQL MaxDB Web Agent Multiple Denial of Service Vulnerabilities Date: Wed, 19 Jan 2005 16:03:46 -0500 From: Michael Sutton [EMAIL PROTECTED] To: bugtraq@securityfocus.com, [EMAIL PROTECTED] X-Folder: [EMAIL PROTECTED] MySQL MaxDB Web Agent Multiple Denial of Service Vulnerabilities iDEFENSE Security Advisory 01.19.05 www.idefense.com/application/poi/display?id=187type=vulnerabilities January 19, 2005 I. BACKGROUND MaxDB by MySQL is a re-branded and enhanced version of SAP DB, SAP AG's open source database. MaxDB is a heavy-duty, SAP-certified open source database that offers high availability, scalability and a comprehensive feature set. MaxDB complements the MySQL database server, targeted for large mySAP ERP environments and other applications that require maximum enterprise-level database functionality. Further details are available at: http://www.mysql.com/products/maxdb/ II. DESCRIPTION Two remotely exploitable denial of service conditions have been found to exist in MySQL MaxDB and SAP DB Web Agent products. The first vulnerability specifically exists due to a null pointer dereference in the sapdbwa_GetUserData() function. A remote attacker can request the webdav handler code with invalid parameters to cause a null pointer dereference resulting in a crash of SAP DB Web Agent. The second vulnerability is due to insufficient handling of malformed HTTP headers. A remote attacker can submit a HTTP request with invalid headers to cause a denial of service. III. ANALYSIS A remote attacker can send simple HTTP requests to cause MaxDB Web Agent to crash. IV. DETECTION iDEFENSE has confirmed the existence of these vulnerabilities in MySQL MaxDB 7.5.0.0 on Linux and Windows platforms. It is believed that all versions prior to 7.5.0.21 are affected. V. WORKAROUND Employ firewalls, access control lists or other TCP/UDP restriction mechanisms to limit access to administrative systems and services. VI. VENDOR RESPONSE The vulnerability has been addressed in MaxDB 7.5.00.21. Updated binaries (version 7.5.00.23) are available from: http://dev.mysql.com/downloads/maxdb/7.5.00.html VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the following names to these issues: CAN-2005-0081 MySQL MaxDB Web Agent Null HTTP Header Denial of Service Vulnerability CAN-2005-0082 MySQL MaxDB Web Agent GetUserData Denial of Service Vulnerability VIII. DISCLOSURE TIMELINE 08/20/2004 Initial vendor notification 08/24/2004 Initial vendor response 01/19/2005 Public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp VII. LEGAL NOTICES Copyright (c) 2005 iDEFENSE, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDEFENSE. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. - End forwarded message - -- Every use of Linux is a proper
Bug#291503: CAN-2005-0129/130/131: Multiple vulnerabilities in Konversation
Nathaniel W. Turner wrote: On Friday 21 January 2005 02:09 am, Martin Schulze wrote: These problems have been discovered by Wouter Coekaerts in the konversation IRC client. Affected are version 0.15, CVS until 18-19/01/2005, and some older versions too. They are fixed in 0.15.1. Fixed in 0.15-3, which needs to be uploaded by a DD. I mailed Riku Voipio (who usually sponsors my konversation uploads) about it a couple days ago. For now, the fixed package can be found at my repository: deb http://debian.houseofnate.net/ unstable main deb-src http://debian.houseofnate.net/ unstable main Great. In case the new upload auto-closes this bug, please reopen it for the release team as a note to take care of the package. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291681: Mail improvements
Package: bugs.debian.org Severity: wishlist I'd like to propose two improvements for our bugtracking system: 1. To: address correction in X-Debbugs-Cc It would be nice, if mails sent to me via the X-Debbugs-Cc: command would not contain To: Debian Bug Tracking System [EMAIL PROTECTED] but have [EMAIL PROTECTED] replaced by [EMAIL PROTECTED] 2. To: address correction in mbox export The same applies to the mbox file one can download via doogie's mbox exporter. It would be nice if one could simply reply/group-reply to these mails. Alternatively, the BTS could insert a carefully crafted Mail-Followup-To header if none exists. This wishlist has a connection to Bug#284709. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291566: libavcodec-dev: Multiple integer overflows, some of them may lead to arbitrary code execution
Moritz Muehlenhoff wrote: Package: libavcodec-dev Version: 0.cvs20050106-1 Severity: grave Tags: security Justification: user security hole [Cc'ing security@, as at least xine-lib embeds libavcodec, there may be more, I haven't investigated whether they are affected, but I assume it's the case] Thanks, however the version of xine-lib in woody doesn't seem to be affected since only libavcodec but not libavformat is embedded. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290518: libc6-sparc64: trying to overwrite `/usr/lib/64', which is also in package fakeroot
Norbert Veber wrote: On Fri, Jan 14, 2005 at 10:44:13AM -0500, Norbert Veber wrote: Package: libc6-sparc64 Version: 2.2.5-11.8 Severity: normal Preparing to replace libc6-sparc64 2.2.5-11.5 (using .../libc6-sparc64_2.2.5-11.8_sparc.deb) ... Unpacking replacement libc6-sparc64 ... dpkg: error processing /var/cache/apt/archives/libc6-sparc64_2.2.5-11.8_sparc.deb (--unpack): trying to overwrite `/usr/lib/64', which is also in package fakeroot When will this be fixed? This security update has completely broken the package and rendered it uninstalable. This is not just any package, its part of the base system. I guess my bug report should have had its severity set to serious to better reflect the severity of the problem, though I thought it was obvious. It probably won't be fixed since this problem wasn't introduced by the security update (as you can find out by diffing older versions). Regards, Joey -- All language designers are arrogant. Goes with the territory... -- Larry Wall Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292458: Openswan XAUTH/PAM Buffer Overflow Vulnerability
Rene Mayrhofer wrote: http://www.idefense.com/application/poi/display?id=190type=vulnerabilitiesflashstatus=false Even though iDEFENSE wrote: iDEFENSE has confirmed that Openswan 2.2.0 is vulnerable. All previous versions of Openswan also contain the vulnerable code. it seems that 2.3.0 in sid is vulnerable as well. Many thanks for informing me about this - I have somehow missed the announcement (it does not seem to have been communicated over the openswan announce mailing list either). I now have two packages ready, one 2.2.0 based for testing (IMHO 2.3.0 should not enter testing in its current state - it is broken upstream) and one 2.3.0 based for unstable which both fix the mentioned security issue. How should I proceed? Upload one to unstable, the other to testing as soon as you are prepared to release the DSA? When you are pondering an upload only for testing it has to go through testing-proposed-updates. Please talk to the release team on debian-release@lists.debian.org prior to the upload first. Since we're waiting for testing-security for at least four months and we have no idea when it will be up and running, waiting for it is not an alternative. If the unstable package should not enter testing you'll also have to file an RC bug to keep it out. Regards, Joey -- Of course, I didn't mean that, which is why I didn't say it. What I meant to say, I said. -- Thomas Bushnell Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292458: CVE Id
== Candidate: CAN-2005-0162 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0162 Reference: IDEFENSE:20050126 Openswan XAUTH/PAM Buffer Overflow Vulnerability Reference: URL:http://www.idefense.com/application/poi/display?id=190type=vulnerabilities Stack-based buffer overflow in the get_internal_addresses function in the pluto application for Openswan 1.x before 1.0.9, and Openswan 2.x before 2.3.0, when compiled XAUTH and PAM enabled, allows remote authenticated attackers to execute arbitrary code. Please mention this id in the changelog (could be done with the next upload if you've already uploaded the fixed package. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292458: CVE Id
Rene Mayrhofer wrote: Hi Joey, On Friday 28 January 2005 07:28, Martin Schulze wrote: Stack-based buffer overflow in the get_internal_addresses function in the pluto application for Openswan 1.x before 1.0.9, and Openswan 2.x before 2.3.0, when compiled XAUTH and PAM enabled, allows remote authenticated attackers to execute arbitrary code. I still think that the bug is present in 2.3.0 too. At least I applied the patch also to this release - which has the same (flawed) definition of the src variable. I'll forward this. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292759: shell script sniplets in /usr/bin?
Adrian von Bidder wrote: You wouldn't need to change every script - you just need to move gettext.sh to /usr/share/gettext/scripts and create /usr/bin/gettext.sh with the content Sean suggested. Which buys us what? This new gettext.sh would still be a non-executable script snippet which is not intended to be called by the user directly, as far as I can understand. But it has the executable flag turned on which makes it executable by users - and we'll get bug reports about useless scripts polluting /usr/bin. Err... Is that really an advantage over the current situation? Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366004: bash completion for cdcd
Package: cdcd
Severity: wishlist
Hi,
attached please find a simple function for bash completion for the
cdcd command. I'd be glad if it would be added to future versions.
License is GPLv2 or higher, same as for cdcd itself.
Regards,
Joey
--
It's practically impossible to look at a penguin and feel angry.
Please always Cc to me when replying to me on the lists.
# put this in your bashrc for bash tab completion with mpc
# $ cat cdcd-bashrc ~/.bashrc
ismember()
{
local elm=$1; shift
local pivot
for pivot in $*
do
if [ $pivot = $elm ]
then
return 0
fi
done
return 1
}
_cdcd_complete_func ()
{
cur=${COMP_WORDS[COMP_CWORD]}
first=${COMP_WORDS[1]}
second=${COMP_WORDS[2]}
commands=`cdcd help|grep -v 'For more'`
commands=${commands#Commands: }
commands=${commands//,/}
commands=${commands/./}
if ismember $first $commands
then
COMPREPLY=
return 0
fi
case $first in
*)
COMPREPLY=($(compgen -W ${commands} ${cur}))
return 0
;;
esac
}
complete -F _cdcd_complete_func cdcd
Bug#365680: CGIIRC vulnerability (Bug#365680)
Elrond wrote: Nearly all the relevant information, that is currently available regarding this issue, is in the bug logs. (see: http://bugs.debian.org/365680) Are you going to update the package in sid as well? Or should the package propagate via stable-security? Regards, Joey -- It's practically impossible to look at a penguin and feel angry. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365680: CGIIRC vulnerability (Bug#365680)
Elrond wrote: Nearly all the relevant information, that is currently available regarding this issue, is in the bug logs. (see: http://bugs.debian.org/365680) Very Short summary: * bufferoverflow in C code * remotely exploitable * CVE has been requested by micah * Untested patch exists I _might_ be able to test, wether the package still works with the patch within the next 24 to 48 hours, but don't hold your breath on this. Please let us know. As this has been disclosed publicly now anyway, I'd suggest keeping all important (new) information in the bug logs for easy review by interested parties. Update prepared. Regards, Joey -- It's practically impossible to look at a penguin and feel angry. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365680: CGIIRC vulnerability (Bug#365680)
Mario 'BitKoenig' Holbe wrote: Elrond wrote: I _might_ be able to test, wether the package still works Please let us know. Tests are done. Everything seems to work well. Update prepared. Go on :) Please make sure you did also add 50_client-c_bufferoverflow_fix to debian/patches/00list in order to really make it active, since Elrond did forget to mention this in his original ToDo list. Yup, did that. Regards, Joey -- It's practically impossible to look at a penguin and feel angry. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365680: CGIIRC vulnerability (Bug#365680)
Elrond wrote: On Sun, May 07, 2006 at 09:16:35AM +0200, Martin Schulze wrote: [...] If an update enters stable-security and the version in testing ist the same as in stable, then the new version propagates into testing. If, additionally, the version in unstable is the same, this very version will propagate into unstable as well. So, it'll propagate automatically if you're not updating the package before. Very nice! What's missing for the DSA? (just curious / wanting to know, if there's something I should do) Nothing else required by you. Regards, Joey -- It's practically impossible to look at a penguin and feel angry. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366682: CVE-2006-2162: Buffer overflow in nagios
sean finney wrote:
hey security team and nagios team,
as reported to us in the bts, the debian nagios packages are vulnerable
to arbitrary code execution via not properly checking the Content-Length
header from client requests.
here are the affected versions afaict:
stable:
nagios-mysql 2:1.3-cvs.20050402-2.sarge.1
nagios-text 2:1.3-cvs.20050402-2.sarge.1
nagios-pgsql 2:1.3-cvs.20050402-2.sarge.1
unstable:
nagios-mysql 2:1.3-cvs.20050402-13
nagios-text 2:1.3-cvs.20050402-13
nagios-pgsql 2:1.3-cvs.20050402-13
nagios2 2.2-1
in unstable both the 1.x and 2.x trees have had updates from upstream.
i've just finished putting the changes into svn, but i haven't prepared
an upload yet because i haven't been able to find/craft an exploit
just yet, and i'm in one of those low on time modes where it's
possible i may have messed something up.
so, i could use help with the following two things:
- crafting a simple user-agent that can illustrate the vulnerability
by sending a negative or 0 value for content length to a nagios cgi
(it doesn't have to actually inject any shell code or anything, just
PoC would be fine by me).
Why user-agent? All you need to do is add some variables, so that
the Content-Length is either exactly INT_MAX or even larger, both
cause an integer overrun, which cause a negative malloc() which cause
a situation in which the attacker may control some memory they shouldn't.
I'm attaching a patch that ought to fix the problem.
Please note that upstream doesn't check for content length == INT_MAX
but blindly adds 1.
Regards,
Joey
--
Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier
Please always Cc to me when replying to me on the lists.
diff -u nagios-1.3-cvs.20050402/debian/patches/00list
nagios-1.3-cvs.20050402/debian/patches/00list
--- nagios-1.3-cvs.20050402/debian/patches/00list
+++ nagios-1.3-cvs.20050402/debian/patches/00list
@@ -12,0 +13 @@
+9_CVE-2006-2162.dpatch
diff -u nagios-1.3-cvs.20050402/debian/changelog
nagios-1.3-cvs.20050402/debian/changelog
--- nagios-1.3-cvs.20050402/debian/changelog
+++ nagios-1.3-cvs.20050402/debian/changelog
@@ -1,3 +1,11 @@
+nagios (2:1.3-cvs.20050402-2.sarge.2) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Add overflow protection for Content-Length [cgi/getcgi.c,
+debian/patches/9_CVE-2006-2162.dpatch]
+
+ -- Martin Schulze [EMAIL PROTECTED] Thu, 11 May 2006 17:34:58 +0200
+
nagios (2:1.3-cvs.20050402-2.sarge.1) unstable; urgency=high
* Sean Finney:
only in patch2:
unchanged:
--- nagios-1.3-cvs.20050402.orig/debian/patches/9_CVE-2006-2162.dpatch
+++ nagios-1.3-cvs.20050402/debian/patches/9_CVE-2006-2162.dpatch
@@ -0,0 +1,28 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 10_grouplist.cgi-pathfixes.dpatch by [EMAIL PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: prevent integer overflow
+
[EMAIL PROTECTED]@
+--- nagios-1.3-cvs.20050402/cgi/getcgi.c~ 2006-05-11 17:43:35.0
+0200
nagios-1.3-cvs.20050402/cgi/getcgi.c 2006-05-11 17:43:00.0
+0200
+@@ -9,6 +9,7 @@
+ #include ../common/config.h
+ #include stdio.h
+ #include stdlib.h
++#include limits.h
+ #include getcgi.h
+
+
+@@ -166,6 +167,10 @@ char **getcgivars(void){
+ printf(getcgivars(): No Content-Length was sent with
the POST request.\n) ;
+ exit(1);
+ }
++ if((content_length0) || (content_length = INT_MAX-1)){
++ printf(getcgivars(): Suspicious Content-Length was
sent with the POST request.\n);
++ exit(1);
++ }
+ if(!(cgiinput=(char *)malloc(content_length+1))){
+ printf(getcgivars(): Could not allocate memory for CGI
input.\n);
+ exit(1);
signature.asc
Description: Digital signature
Bug#366682: CVE-2006-2162: Buffer overflow in nagios
Hi Sean! Sean Finney wrote: On Thu, May 11, 2006 at 05:46:16PM +0200, Martin Schulze wrote: - crafting a simple user-agent that can illustrate the vulnerability by sending a negative or 0 value for content length to a nagios cgi (it doesn't have to actually inject any shell code or anything, just PoC would be fine by me). Why user-agent? All you need to do is add some variables, so that as a general rule i feel much more comfortable having some kind of PoC code available that will tell me that my patch works. granted, in this case it's a rather straightforward patch, but still... the Content-Length is either exactly INT_MAX or even larger, both cause an integer overrun, which cause a negative malloc() which cause a situation in which the attacker may control some memory they shouldn't. ah yes.. good point about INT_MAX. i'll forward this upstream as well, since i don't think ethan considered this. Thanks. Please let me know the version in sid that will have this problem fixed once you know it. Regards, Joey -- It's time to close the windows. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366927: CVE-2006-2247: Information leak in webcalendar
Package: webcalendar
Severity: grave
Tags: security sid etch
David Maciejak noticed that webcalendar, a PHP-Based multi-user
calendar, returns different error messages on login attempts for an
invalid password and a non-existing user, allowing remote attackers to
gain information about valid usernames.
The patch for the version in sarge is attached to this mail.
Regards,
Joey
--
It's time to close the windows.
Please always Cc to me when replying to me on the lists.
diff -u webcalendar-0.9.45/debian/changelog webcalendar-0.9.45/debian/changelog
--- webcalendar-0.9.45/debian/changelog
+++ webcalendar-0.9.45/debian/changelog
@@ -1,3 +1,11 @@
+webcalendar (0.9.45-4sarge4) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Unified error messages for unknown users and wrong passwords to
+prevent an information leak [includes/user.php, CVE-2006-2247]
+
+ -- Martin Schulze [EMAIL PROTECTED] Fri, 12 May 2006 08:10:15 +0200
+
webcalendar (0.9.45-4sarge3) stable-security; urgency=high
* Fixed multiple security vulnerabilities
only in patch2:
unchanged:
--- webcalendar-0.9.45.orig/includes/user.php
+++ webcalendar-0.9.45/includes/user.php
@@ -41,8 +41,7 @@
if ( $row[0] == $login )
$ret = true; // found login/password
else
-$error = translate (Invalid login) . : .
- translate(incorrect password);
+$error = translate (Invalid login);
} else {
$error = translate (Invalid login);
// Could be no such user or bad password
@@ -53,12 +52,10 @@
$row = dbi_fetch_row ( $res2 );
if ( $row ! empty ( $row[0] ) ) {
// got a valid username, but wrong password
- $error = translate (Invalid login) . : .
-translate(incorrect password );
+ $error = translate (Invalid login);
} else {
// No such user.
- $error = translate (Invalid login) . : .
-translate(no such user );
+ $error = translate (Invalid login);
}
dbi_free_result ( $res2 );
}
Bug#364443: [Pkg-awstats-devel] Bug#364443: Vulnerability exists also with the 'diricons' parameter
How can the diricons and config parameters be exploited? From a quick
glance I can't find an open associated with $DirIcons.
I assume $SiteConfig leads to an open() call.
Charles Fry wrote:
Index: awstats-6.5/wwwroot/cgi-bin/awstats.pl
===
--- awstats-6.5.orig/wwwroot/cgi-bin/awstats.pl 2005-11-24
15:11:19.0 -0500
+++ awstats-6.5/wwwroot/cgi-bin/awstats.pl2006-05-05 16:43:12.0
-0400
@@ -5542,8 +5542,8 @@
# No update but report by default when run from a browser
$UpdateStats=($QueryString=~/update=1/i?1:0);
- if ($QueryString =~ /config=([^]+)/i) {
$SiteConfig=DecodeEncodedString($1); }
- if ($QueryString =~ /diricons=([^]+)/i){
$DirIcons=DecodeEncodedString($1); }
+ if ($QueryString =~ /config=([^]+)/i) {
$SiteConfig=Sanitize(DecodeEncodedString($1)); }
+ if ($QueryString =~ /diricons=([^]+)/i){
$DirIcons=Sanitize(DecodeEncodedString($1)); }
if ($QueryString =~ /pluginmode=([^]+)/i) {
$PluginMode=Sanitize(DecodeEncodedString($1),1); }
if ($QueryString =~ /configdir=([^]+)/i) {
$DirConfig=Sanitize(DecodeEncodedString($1)); }
# All filters
@@ -5561,7 +5561,7 @@
# If migrate
if ($QueryString =~ /(^|-||amp;)migrate=([^]+)/i){
- $MigrateStats=DecodeEncodedString($2);
+ $MigrateStats=Sanitize(DecodeEncodedString($2));
$MigrateStats =~
/^(.*)$PROG(\d{0,2})(\d\d)(\d\d\d\d)(.*)\.txt$/;
$SiteConfig=$5?$5:'xxx'; $SiteConfig =~ s/^\.//;
# SiteConfig is used to find config file
}
@@ -5591,8 +5591,8 @@
# Update with no report by default when run from command line
$UpdateStats=1;
- if ($QueryString =~ /config=([^]+)/i) {
$SiteConfig=$1; }
- if ($QueryString =~ /diricons=([^]+)/i){
$DirIcons=$1; }
+ if ($QueryString =~ /config=([^]+)/i) {
$SiteConfig=Sanitize($1); }
+ if ($QueryString =~ /diricons=([^]+)/i){
$DirIcons=Sanitize($1); }
if ($QueryString =~ /pluginmode=([^]+)/i) {
$PluginMode=Sanitize($1,1); }
if ($QueryString =~ /configdir=([^]+)/i) {
$DirConfig=Sanitize($1); }
# All filters
Regards,
Joey
--
It's time to close the windows.
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364443: [Pkg-awstats-devel] Bug#364443: Vulnerability exists also with the 'diricons' parameter
Hendrik Weimer wrote: Martin Schulze [EMAIL PROTECTED] writes: How can the diricons and config parameters be exploited? From a quick glance I can't find an open associated with $DirIcons. The diricons issue is a XSS vulnerability. It has nothing to do with the two other holes (which lead to arbitrary code execution) other than they all are a case of missing input sanitizing. Umh... but since the query_string is already sanitised globally how can XSS still happen? Was the sanitising not sucessful? Regards, Joey -- It's time to close the windows. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364443: [Pkg-awstats-devel] Bug#364443: Vulnerability exists also with the 'diricons' parameter
Hendrik Weimer wrote: Martin Schulze [EMAIL PROTECTED] writes: Umh... but since the query_string is already sanitised globally how can XSS still happen? Was the sanitising not sucessful? AFAICS the query_string is not being decoded first. Therefore, a '' encoded as %3E will slip through. Version 6.5-2 contains the proper fix. It does. I understand now. Regards, Joey -- It's time to close the windows. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366683: CVE-2006-2162: Buffer overflow in nagios
Sean Finney wrote: On Fri, May 12, 2006 at 06:24:21AM +0200, Martin Schulze wrote: Please let me know the version in sid that will have this problem fixed once you know it. for nagios 1.x: 1.4-1 (or 2:1.4-1, since there's an epoch i guess) for nagios 2.x: 2.3-1 Noted. both are recently uploaded. i've made a diff.gz of the sarge version available at: http://people.debian.org/~seanius/nagios/nagios_1.3-cvs.20050402-2.sarge.2.diff.gz The other version is already built, though. Regards, Joey -- Linux - the choice of a GNU generation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296340: lynx: patch to fix CVE-2004-1617
Alec Berryman wrote: Package: lynx Version: 2.8.5-2sarge1 Followup-For: Bug #296340 Attached is a patch from OpenBSD to fix CVE-2004-1617. It has been reformatted as a dpatch. After applying the patch and rebuilding, pages like http://lcamtuf.coredump.cx/mangleme/gallery/lynx_die1.html no longer causes lynx to exhaust memory and crash. Patch obtained from: ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.6/common/004_lynx.patch Thanks a lot. I can confirm that the patch works and looks good. Will puth the three packages into the buildd network. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365940: Files for a Quagga DSA (RIPD unauthenticated route injection)
Christian Hammers wrote: Attached you will find a diff that can be used to make a DSA for the recent Quagga security bug. Thanks a lot for preparing the update. Please also mention CVE-2006-2223 CVE-2006-2224 in the unstable changelog when you're doing the next upload anyway. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296340: lynx: patch to fix CVE-2004-1617
Thomas Dickey wrote: reformatted as a dpatch. After applying the patch and rebuilding, pages like http://lcamtuf.coredump.cx/mangleme/gallery/lynx_die1.html no longer causes lynx to exhaust memory and crash. Patch obtained from: ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.6/common/004_lynx.patch Thanks a lot. I can confirm that the patch works and looks good. Will puth the three packages into the buildd network. That's a piece of my patch for lynx 2.8.6dev.8, which one can see here: Oh. I see. I'm sorry for the wrong credits. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351834: nl_langinfo(3) lacks precondition
Michael Kerrisk wrote: is nl_langinfo(3) somehow different here from a host of other functions whose behaviour depends on setlocale(). E.g., strptime(3), printf(3), etc, most of which do not explicitly mention the need to call setlocale()? Not sure about the other functions you mentioned but for nl_langinfo you'll have to execute setlocale first. Please see the attached test program as an example: I've now doubt that calling setlocale() changes the result one gets from nl_langinfo. But this doesn't seem to me any different than a number of other functions that are modified by calling setlocale(). The way that this is generally documented on those pages is under SEE ALSO. That was why I asked: how is nl_langinfo() different? *shrug* I have to give up. Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367272: FreeTalk should allow users to overwrite system defaults
Package: freetalk Version: 0.5-2 Currently, freetalk loads a lot of files upon startup. One of them is beep.scm. However, some users may prefer the client not to beep upon each and every message. You guessed it, I am among those. However,.freetalk/freetalk.scm is loaded before init.scm, the systemwide init script is evaluated. Due to this, the system wide settings always overwrite local settings. Interestingly, init.scm already has a hook for adding local extensions after the login. It's just not evaluated and the respective file is not there. Hence, I've taken the opportunity of writing one, so that the user can place post-login.scm in their .freetalk directory. If it exists, the file will be evaluated, and the user is able to overwrite system-wide defaults, just as one would expect it. Please consider adding this to the Debian package and maybe even forwarding it upstream. The patch for init.scm and the post-login-extensions-here.scm file are attached. Regards, Joey -- Of course, I didn't mean that, which is why I didn't say it. What I meant to say, I said. -- Thomas Bushnell Please always Cc to me when replying to me on the lists. --- init.scm.orig 2006-05-14 21:58:23.0 +0200 +++ init.scm2006-05-14 21:58:32.0 +0200 @@ -48,7 +48,7 @@ ;; FIXME: login.scm should not be loaded when run in script mode. ; (ft-load login.scm) - ; (ft-load post-login-extensions-here.scm) + (ft-load post-login-extensions-here.scm) ) (lambda (k args . opts) (display \n~qp~ ~qp~ ~qp~ ~qp~ ~qp~ ~qp~) ;;; post-login-extensions-here.scm: load private post-login.scm ;;; author: Joey Schulze [EMAIL PROTECTED] ;;; Copyright 2006 ;;; This program is free software; you can redistribute it and/or ;;; modify it under the terms of the GNU General Public License as ;;; published by the Free Software Foundation; either version 2, or (at ;;; your option) any later version. ;;; ;;; This program is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ;;; General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this program; if not, write to the Free Software ;;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA (let ((fname (string-append (getenv HOME) / .freetalk/post-login.scm))) (if (file-exists? fname) (ft-load fname) ) )
Bug#358061: mutt: Mutt should filter control characters from headers
Vincent Lefevre wrote: Package: mutt Version: 1.5.11+cvs20060126-2 Severity: grave Tags: security Justification: user security hole Mutt doesn't filter control characters, in particular the ^J and ^M, from headers, which can lead to unwanted behavior; in particular when replying, the reply can be sent to a 3rd address given in the Subject (and the user won't probably notice it). More details are given here: It seems to me that this problem only exists when edit_headers is set. However, with this option set the user sees the receipients of the mail and can edit the header fields. In that, it is comparable to specifying 'Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] or using the famous Mail-Followup-To: header. Hence, I don't consider this bug warrants an update via security.debian.org. It may be serious enough to justify an update in stable via proposed-updates, though. Please talk to the stable release people about it. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359332: boinc-client: Description improvement
Package: boinc-client lia href=http://packages.debian.org/unstable/net/boinc-client;boinc-client/a -- BOINC core client./li lia href=http://packages.debian.org/unstable/devel/boinc-dev;boinc-dev/a -- BOINC platform for distributed computing (development files)./li lia href=http://packages.debian.org/unstable/x11/boinc-manager;boinc-manager/a -- control and monitor utility for the BOINC core client./li So what the heck is a BOINC core client? Please describe the package and don't simply repeat the name of the package. Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359334: pyqonsole: Description improvement
Package: pyqonsole Description: console program written in Python What the heck does this package provide? Please use a descriptive short description. A good example can be extracted from the long description, 1st sentence: X Window terminal written in Python Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359626: rtpproxy: Description improvement
Package: rtpproxy Version: current Severity: minor Description: RTP proxy for SER Err... yes... the name implies that it's an RTP proxy. However, what is RTP? Who is SER? And why does it have to be a Debian package? Can't SER use it without Debian? Please craft a short description that help people to understand what's inside the package. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351373: tempfile should honor TMPDIR=1
Package: perl-modules Version: 5.8.7-10 Severity: wishlist The function tempfile() does not behave like tempdir() when this is what the user expects. In detail, according to the documentation TMPDIR = 1 is honoured by tempdir() and since other optional arguments are the same for tempfile() and since it seems logical to have tempfile() create a temporary file in the common temporary directory, people expect TMPDIR = 1 to work with tempfile() as well. However, this is not the case. Please see Bug#350954 and Bug#344029 as reference. It would be nice if tempfile() would honour this optional parameter as well. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344029: [EMAIL PROTECTED]: Bug#350954: DSA-960-1 security update breaks libmail-audit-perl when $ENV{HOME} is not set]
Niko Tyni wrote:
Hi security team,
I'm very sorry that you have to hear from me again :(
There's a regression in the patch for DSA-960-1, for both woody and sarge.
When $HOME is not set, Mail::Audit is now creating logfiles in cwd and
dying if it's not writable. This happens even if logging is turned off,
which makes the problem much more serious.
Doo, I have to agree that it is confusing to have tempdir() use different
parameters as tempfile(), but only partially.
I have not yet had a proper look at the proposed patches in #350954 and
the last message of #344029, but I wanted to make you aware of this.
Again, my apologies for the bad handling of this.
Comments to the attached patch, which are least intrusive to the
update we're already distributing?
Regards,
Joey
--
MIME - broken solution for a broken design. -- Ralf Baechle
Please always Cc to me when replying to me on the lists.
diff -u libmail-audit-perl-2.1/Audit.pm libmail-audit-perl-2.1/Audit.pm
--- libmail-audit-perl-2.1/Audit.pm
+++ libmail-audit-perl-2.1/Audit.pm
@@ -4,7 +4,13 @@
my $logging;
my $loglevel=3;
-my $logfile = /tmp/.getpwuid($).-audit.log;
+my $logfile;
+if (exists $ENV{HOME} and defined $ENV{HOME} and -d $ENV{HOME}) {
+ $logfile = $ENV{HOME}/.mail_audit.log;
+}
+else {
+ (undef,$logfile) = tempfile(mail_audit.log-X, DIR =
File::Spec-tmpdir);
+}
# --
# no user-modifiable parts below this line.
@@ -18,6 +24,8 @@
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK $ASSUME_MSGPREFIX);
# @ISA will depend on whether the message is MIME; if it is, we'll be
MIME::Entity. if not, we'll be Mail::Internet.
use Fcntl ':flock';
+use File::Spec;
+use File::Temp qw(tempfile);
$ASSUME_MSGPREFIX = 0;
--- libmail-audit-perl-2.1.orig/Audit/MimeEntity.pm
+++ libmail-audit-perl-2.1/Audit/MimeEntity.pm
@@ -4,6 +4,7 @@
use strict;
use File::Path;
+use File::Temp qw(tempdir);
use MIME::Parser;
use MIME::Entity;
use Mail::Audit::MailInternet;
@@ -12,10 +13,12 @@
$VERSION = '2.0';
-$MIME_PARSER_TMPDIR = /tmp/.getpwuid($).-mailaudit;
-
my $parser = MIME::Parser-new();
+# Create a tempdir using File::Temp::tempdir, have it be destroyed at
+# END{} time.
+$MIME_PARSER_TMPDIR = tempdir(CLEANUP = 1);
+
my @to_rmdir;
sub autotype_new {
@@ -23,8 +26,6 @@
my $mailinternet = shift;
$parser-ignore_errors(1);
-mkdir ($MIME_PARSER_TMPDIR, 0777);
-if (! -d $MIME_PARSER_TMPDIR) { $MIME_PARSER_TMPDIR = /tmp }
$parser-output_under($MIME_PARSER_TMPDIR);
# todo: add eval error trapping. if there's a problem, return
Mail::Audit::MailInternet as a fallback.
diff -u libmail-audit-perl-2.1/Audit.pm libmail-audit-perl-2.1/Audit.pm
--- libmail-audit-perl-2.1/Audit.pm
+++ libmail-audit-perl-2.1/Audit.pm
@@ -6,10 +6,10 @@
my $loglevel=3;
my $logfile;
if (exists $ENV{HOME} and defined $ENV{HOME} and -d $ENV{HOME}) {
- $logfile = $ENV{HOME}/.mail_audit.log
+ $logfile = $ENV{HOME}/.mail_audit.log;
}
else {
- (undef,$logfile) = tempfile(mail_audit.log-X,TMPDIR=1);
+ (undef,$logfile) = tempfile(mail_audit.log-X, DIR =
File::Spec-tmpdir);
}
# --
@@ -24,6 +24,7 @@
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK $ASSUME_MSGPREFIX);
# @ISA will depend on whether the message is MIME; if it is, we'll be
MIME::Entity. if not, we'll be Mail::Internet.
use Fcntl ':flock';
+use File::Spec;
use File::Temp qw(tempfile);
$ASSUME_MSGPREFIX = 0;
Bug#322535: evolution CVE-2005-2549/CVE-2005-2550
Moritz Muehlenhoff wrote:
Dear security team,
so far there hasn't been a security update for the latest evolution
vulnerabilities. (CVE-2005-2549/CVE-2005-2550)
I've attached patches for Woody and Sarge. The Sarge fixes are
straightforward,
but some comments on Woody, relative to the patch hunks from the Sarge fix:
- accum_attribute() isn't present in Woody, so hunk 1-3 are void.
- the vulnerable code from e-cal-component-preview.c isn't present either.
- the vulnerable code from e-calendar-table.c and e-calendar-view.c is
contained
in Woody, although in a different place. This is exploitable as well, have a
look at the description of the function that feeds data into ical_string:
| * cal-client/cal-client.c (cal_client_get_component_as_string): new
| function to return a complete VCALENDAR string containing a VEVENT
| or VTODO with all the VTIMEZONEs it uses.
Please go ahead.
Regards,
Joey
Cheers,
Moritz
diff -Naur evolution-2.0.4.orig/addressbook/gui/widgets/eab-contact-display.c
evolution-2.0.4/addressbook/gui/widgets/eab-contact-display.c
--- evolution-2.0.4.orig/addressbook/gui/widgets/eab-contact-display.c
Mon Feb 14 17:09:03 2005
+++ evolution-2.0.4/addressbook/gui/widgets/eab-contact-display.c Fri Nov
25 16:50:43 2005
@@ -338,7 +338,7 @@
accum_attribute (accum, contact, _(Yahoo), E_CONTACT_IM_YAHOO_HOME_1,
YAHOO_ICON, 0);
if (accum-len 0)
- gtk_html_stream_printf (html_stream, accum-str);
+ gtk_html_stream_printf (html_stream, %s, accum-str);
end_block (html_stream);
@@ -353,7 +353,7 @@
if (accum-len 0) {
start_block (html_stream, _(work));
- gtk_html_stream_printf (html_stream, accum-str);
+ gtk_html_stream_printf (html_stream, %s, accum-str);
end_block (html_stream);
}
@@ -368,7 +368,7 @@
if (accum-len 0) {
start_block (html_stream, _(personal));
- gtk_html_stream_printf (html_stream, accum-str);
+ gtk_html_stream_printf (html_stream, %s, accum-str);
end_block (html_stream);
}
diff -Naur evolution-2.0.4.orig/calendar/gui/e-cal-component-preview.c
evolution-2.0.4/calendar/gui/e-cal-component-preview.c
--- evolution-2.0.4.orig/calendar/gui/e-cal-component-preview.c Sun Apr
18 20:01:19 2004
+++ evolution-2.0.4/calendar/gui/e-cal-component-preview.cFri Nov 25
16:50:43 2005
@@ -285,7 +285,7 @@
str = g_string_append_c (str,
text.value[i]);
}
- gtk_html_stream_printf (stream, str-str);
+ gtk_html_stream_printf (stream, %s, str-str);
g_string_free (str, TRUE);
}
diff -Naur evolution-2.0.4.orig/calendar/gui/e-calendar-table.c
evolution-2.0.4/calendar/gui/e-calendar-table.c
--- evolution-2.0.4.orig/calendar/gui/e-calendar-table.c Fri Sep 24
17:49:27 2004
+++ evolution-2.0.4/calendar/gui/e-calendar-table.c Fri Nov 25 16:50:43 2005
@@ -1212,7 +1212,7 @@
return;
}
- fprintf (file, ical_string);
+ fprintf (file, %s, ical_string);
g_free (ical_string);
fclose (file);
}
diff -Naur evolution-2.0.4.orig/calendar/gui/e-calendar-view.c
evolution-2.0.4/calendar/gui/e-calendar-view.c
--- evolution-2.0.4.orig/calendar/gui/e-calendar-view.c Mon Feb 14
17:09:04 2005
+++ evolution-2.0.4/calendar/gui/e-calendar-view.cFri Nov 25 16:50:43 2005
@@ -1074,7 +1074,7 @@
return;
}
- fprintf (file, ical_string);
+ fprintf (file, %s, ical_string);
g_free (ical_string);
fclose (file);
diff -Naur evolution-1.0.5.orig/calendar/gui/dialogs/comp-editor.c
evolution-1.0.5/calendar/gui/dialogs/comp-editor.c
--- evolution-1.0.5.orig/calendar/gui/dialogs/comp-editor.c 2002-02-19
16:33:02.0 +0100
+++ evolution-1.0.5/calendar/gui/dialogs/comp-editor.c2005-12-01
15:01:23.0 +0100
@@ -1088,7 +1088,7 @@
return;
}
- fprintf (file, ical_string);
+ fprintf (file, %s, ical_string);
g_free (ical_string);
fclose (file);
--
Reading is a lost art nowadays. -- Michael Weber
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
