Bug#945911: APT leaks repository credentials
Hi, > > > works. If I requests https://a/b/c and it redirects me to https://x/y/z, > > > I need login details for x/y/z to login. > > > > It may well be that you _need_ them. But that doesn't say anything about > > whether you should _get_ them. > > > > When a web server instructs a browser to submit some request to a different > > origin, that request may also _need_ credentials for that other origin to > > perform some operation. But just allowing any web server to submit requests > > to any other origin with all credentials the browser knows about still is > > considered a vulnerability, known as "cross site request forgery". > > The vulnerability you describe in a browser is not that the credentials > are used or that they are leaked somewhere – because they aren't, the > intended receiver gets them – the problem is that with the state already > present in the browser (which can be credentials, but also e.g. cookies) > you can 'automate' things as if the user made that request intentionally > – like deleting the account, authorizing a bank transfer or post some > content. None of these things can happen with apt: It is accessing > static data the user is allowed to receive by knowing the auth, there is > no operation performed or content uploaded the user didn't intend to > allow as there is nothing for them to allow. 1. Yes, the problem with CSRF is very much that credentials are used where they shouldn't be. For one, "credential" is not the name of a protocol field, it's a function of a piece of information. When a cookie authorizes you to perform an operation, then that cookie is a credential. And then, the fact that the credentials are sent to the intended receiver is just completely besides the point, because that is exactly the problem with confused deputy style vulnerabilities: The deputy uses privileges it has (such as credentials that allow it to perform a certain access) to perform an operation requested by a party that doesn't have those privileges and that shouldn't have those privileges. To maybe use a different example: Just because your company's access badge is intended to be presented to your company, does not mean that everything is fine when someone tricks you into presenting your badge in order to get them into the building. (And the solution to CSRF is to require another credential, AKA "CSRF token", when performing operations where the browser security model otherwise would allow confused deputy style attacks, and to keep that credential out of reach for other origins.) 1. Please note that I did not say APT had a CSRF vulnerability. I simply used a different confused deputy style vulnerability that you might be more familiar with to demonstrate a point. So, no, you probably can not get APT to authorize a bank transfer. But, again, the fact that the user is allowed to access the data is completely besides the point. The user is also allowed to look at their bank transactions in their online banking, but still, a browser's security model prevents any other random website from accessing them, because *the other website is not the user*. > > > > Examples for how this could be exploited are: > > > > > > > > - The redirect could point to a different port on the server than where > > > > the > > > > repository is hosted, possibly an unprivileged port where an attacker > > > > on > > > > that server could be listening to receive the credentials. > > > > > > I don't understand. FWIW; credentials can be limited by port, and path. > > > > Yes, they can. But it is absolutely not clear from the documentation that > > you are vulnerable to this type of attack if you don't do that. And even if > > this were stated clearly in the documentation, it would still be bad > > default behaviour. > > The manpage says: > | If no port is given the token matches for all ports And how does it follow that therefore you are vulnerable? > Anyhow, you are either starting from the position of a HTTP source where > you need to be an MITM to make use of this "vulnerability" to … well, do > what you can already do because you are a MITM anyhow. That is the > problem of a HTTP source, we can't fix that. > > Or it is a HTTPS source, but if you can attack those you again don't need > this as you are again a MITM apparently with access to the private > keys of the server which reduces the problem down to HTTP. I have no idea what you are talking about here!? In particular I don't understand where you got that MitM from ... none of the scenarios I described require a MitM!? I mean, yes, a MitM could potentially also exploit some of this, sure, but it's certainly not limited to MitM. > > > > - The redirect could point to an HTTP URI to expose the credentials as > > > > plain text on the wire, even where the sources.list entries for the > > > > respective server point only to HTTPS URIs to protect from > > > >
Bug#945911: APT leaks repository credentials
> > The credentials to transmit for a request are selected not based on the > > host name specified in the sources.list, but rather based on the URI that > > is being requested. Thus, any repository server that APT ever makes an > > HTTP(S) request to can issue an HTTP redirect to any URI that points to any > > of the (other) servers for which credentials are stored in the auth.conf > > file, and APT will then send those credentials to whatever endpoint that is > > specified as the redirection target URI. > > Yes, and why please tell, should that be a problem? That's how stuff Because it might allow operations to happen that the user did not intend to allow. > works. If I requests https://a/b/c and it redirects me to https://x/y/z, > I need login details for x/y/z to login. It may well be that you _need_ them. But that doesn't say anything about whether you should _get_ them. When a web server instructs a browser to submit some request to a different origin, that request may also _need_ credentials for that other origin to perform some operation. But just allowing any web server to submit requests to any other origin with all credentials the browser knows about still is considered a vulnerability, known as "cross site request forgery". Just because https://x/y/z needs credentials to be accessed, does not mean that https://a/b/c should be allowed to cause such an access. > Saying we should send the credentials for a/b/c to x/y/z does not make > a whole lot of sense. Indeed, it doesn't, and maybe I was not entirely clear on this, but I certainly didn't intend to suggest anything like that. > This also assumes that you have access to the a/b/c server _and_ the > x/y/z server. Yes ... so?! > > Examples for how this could be exploited are: > > > > - The redirect could point to a different port on the server than where the > > repository is hosted, possibly an unprivileged port where an attacker on > > that server could be listening to receive the credentials. > > I don't understand. FWIW; credentials can be limited by port, and path. Yes, they can. But it is absolutely not clear from the documentation that you are vulnerable to this type of attack if you don't do that. And even if this were stated clearly in the documentation, it would still be bad default behaviour. > > - The redirect could point to an HTTP URI to expose the credentials as > > plain text on the wire, even where the sources.list entries for the > > respective server point only to HTTPS URIs to protect from eavesdroppers. > > HTTPS->HTTP redirects are not allowed. Well, that's good, I suppose? But it's also irrelevant for this attack scenario?! > > - The redirect could point to an existing resource in the repository the > > credentials are actually meant for in order to make APT download that > > resource and then use it in a context it wasn't meant for, thus > > potentially leaking contents of the password-protected repository. > > I don't understand. You specify in the sources.list: | deb http://public.mirror.example/debian buster main In auth.conf: | machine internal.server.example | login top | password secret Now, when you request some package list or something from public.mirror.example, public.mirror.example could redirect you to http://internal.server.example/whatever/file, and APT would then treat that file as if it were the packages list that is found on public.mirror.example - I suppose? I haven't tried to build a PoC for this, so no clue how exactly you would exploit this particular scenario.
Bug#945911: APT leaks repository credentials
Package: apt Version: 1.8.2 Severity: critical APT now promotes using auth.conf to store repository credentials. Unfortunately, the way these credentials are handled causes a confused deputy style problem: The credentials to transmit for a request are selected not based on the host name specified in the sources.list, but rather based on the URI that is being requested. Thus, any repository server that APT ever makes an HTTP(S) request to can issue an HTTP redirect to any URI that points to any of the (other) servers for which credentials are stored in the auth.conf file, and APT will then send those credentials to whatever endpoint that is specified as the redirection target URI. Examples for how this could be exploited are: - The redirect could point to a different port on the server than where the repository is hosted, possibly an unprivileged port where an attacker on that server could be listening to receive the credentials. - The redirect could point to an HTTP URI to expose the credentials as plain text on the wire, even where the sources.list entries for the respective server point only to HTTPS URIs to protect from eavesdroppers. - The redirect could point to an existing resource in the repository the credentials are actually meant for in order to make APT download that resource and then use it in a context it wasn't meant for, thus potentially leaking contents of the password-protected repository. IMO, credential use should be limited based on the the URI that was derived from the sources.list to prevent such exploits: The user should be able to trust that when they specify credentials for a specific server, say, then only sources.list entries that name that server get to use those credentials. Note: I did not investigate the source on this, I just tested this manually with socat, redirecting from one hostname to a different hostname on a random port, and in that scenario I got the credentials for the redirection target. So, it is possible that some of the scenarios above actually don't work for some reason, though it seems unlikely.
Bug#941414: certificates about to expire
Hi, > Mhh, are you sure? The default with HOOK_CHAIN=no is: > request_challenge → deploy_challenge → testing_challenge → > clean_challenge > repeated for each domain in domains.txt…, and that is still true with > the latest 0.6.5. Looking at the code of the installed backports package, that very much does not seem to be the case (l. 778 ff.). > Either way, I also deploy all my challenges in > /var/lib/dehydrated/acme-challenges and there is no clash, after all > the name of the challenges are all random strings. Could you maybe > confirm what you are seeing and share more details? Indeed, that seems to not be a problem with HTTP challenges, but it is with DNS challenges, if all the _acme_challenge names point to the same canonical name for the dynamically updated TXT record (as they do in my setup). Regards, Florian
Bug#941414: certificates about to expire
Hi, > In fact, the proposed "fix" I'm working on is to actually get the > version that is currently in backports directly in the oldstable > distribution, but I need to tweak it a bit as to do that I need to > reintroduce the 'letsencrypt.sh' compatibility packages/scripts. unfortunately, that version (0.6.2-2+deb10u1~bpo9+1) is not backwards compatible with the current stretch version (0.3.1-3+deb9u2), in that it deploys all challenges for a certificate at once, and only then submits the verification requests for the individual host names. If you happen to deploy challenges for multiple host names to the same location, that fails because the last deployed challenge overwrites all other challenges in that location, and the verification request for the first host name then causes dehydrated to abort (also, without any useful error message). For anyone facing the same problem: A (temporary) workaround I found was to set HOOK_CHAIN=yes, which causes all challenges for a given domain to be deployed in a single call to the hook script. If your hook script simply ignores the additional parameters, that then causes only the first challenge to actually be deployed, and thus the verification for the first host name to succeed. Then you just have to re-run dehydrated until all the host names have been verified. Regards, Florian
Bug#941414: certificates about to expire
Hi, as the recommended strategy by LetsEncrypt is to renew certificates 30 days before their expiry, and we are approaching 30 days since the change that exposed this bug that thus is preventing certificate renewal since then, certificates generated using dehydrated are going to start expiring in about a week. Is there any plan to fix this bug before then, or will users have to work around this individually to avoid running into expired certificates? And if the latter, what is the recommended workaround? Is the current backports version usable? Regards, Florian
Bug#930484: e2fsck corrupts sparse files with -E bmap2extent
Package: e2fsprogs Version: 1.43.4-2 Severity: critical e2fsck potentially moves blocks around in sparse files when running with -E bmap2extent, in particular when the blocks are physically adjacent on the underlying block device, but have a hole in between in the file. This script reproduces the problem on my system (run as root in an empty directory!): #!/bin/bash -ex rm -f image mkdir -p m umount m || true dd if=/dev/zero bs=1M seek=99 count=1 of=image mkfs.ext3 -E nodiscard -b 4096 image mount -o loop image m echo -n a > m/x echo -n b | dd of=m/x bs=1 seek=8k ls -i m/x ino=$(stat -c%i m/x) sha1sum m/x umount m debugfs image -R "stat <$ino>" | cat tune2fs -O extent image e2fsck -fE bmap2extent image || true debugfs image -R "stat <$ino>" | cat mount -o loop image m sha1sum m/x umount m rm image rmdir m The e2fsck invocation turns this part of the debugfs output: BLOCKS: (0):24576, (2):24577 into this: EXTENTS: (0-1):24576-24577 With version 1.44.5-1~bpo9+1, the test above does not produce corruption on my system, but I have not investigated whether that is just coincidence or because the bug has been fixed. As this silently corrupts files, I would think it should get some fix in stretch, and be it by disabling the feature.
Bug#903940: Integer overflow on buffer sizes causes complete failure of driver
Package: libtowitoko2
Version: 2.0.7-9
Severity: grave
Tags: patch
pcscd nowadays passes in buffers much larger than can be represented in an
unsigned short when communicating with the card reader, but libtowitoko2
simply casts the length to an unsigned short, which leads to
overflow/truncation of the buffer size and thus to complete failure to use
the Towitoko reader using this driver.
The attached patch simply limits the buffer sizes that are passed into the
driver to what can be represented in unsigned shorts, which makes it all
work again for me.
diff --git a/src/ifd-handler/ifdhandler.c b/src/ifd-handler/ifdhandler.c
index 5fc0299..b3dbcaa 100644
--- a/src/ifd-handler/ifdhandler.c
+++ b/src/ifd-handler/ifdhandler.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#ifdef HAVE_PTHREAD_H
#include
#endif
@@ -497,15 +498,24 @@ IFDHTransmitToICC (DWORD Lun, SCARD_IO_HEADER SendPci,
#endif
dad = (UCHAR) ((slot == 0) ? 0x00 : slot + 1);
sad = 0x02;
- lr = (unsigned short) (*RxLength);
- lc = (unsigned short) TxLength;
-
- ret = CT_data (ctn, , , lc, TxBuffer, , RxBuffer);
-
- if (ret == OK)
+ lr = ((*RxLength) > USHRT_MAX) ? USHRT_MAX : ((unsigned short) (*RxLength));
+ if (TxLength <= USHRT_MAX)
{
- (*RxLength) = lr;
- rv = IFD_SUCCESS;
+ lc = (unsigned short) TxLength;
+
+ ret = CT_data (ctn, , , lc, TxBuffer, , RxBuffer);
+
+ if (ret == OK)
+{
+ (*RxLength) = lr;
+ rv = IFD_SUCCESS;
+}
+
+ else
+{
+ (*RxLength) = 0;
+ rv = IFD_COMMUNICATION_ERROR;
+}
}
else
Bug#903937: /etc/reader.conf.d/libtowitoko2 causes driver failure
Package: libtowitoko2 Version: 2.0.7-9 Severity: grave /etc/reader.conf.d/libtowitoko2 should not contain a DEVICENAME line as this driver does not support opening readers by device name, but the presence of the line in the config file triggers a bug in pcscd that always causes /dev/ttyS0 to be opened when a DEVICENAME line is present, no matter what else is configured. Instead, it should be documented that "normal" serial devices start at CHANNELID 1 for /dev/ttyS0 and USB devices start at 0x20 for /dev/ttyUSB0, and possibly the automatically generated /etc/reader.conf.d/libtowitoko2 should be removed completely (or made into a conffile), so as to not break a working manual configuration on each update/reinstall, given that the debconf options don't support every possible setup.
Bug#606595: bacula-common: affected by privilege escalation vulnerability in logrotate
Package: bacula-common Version: 2.4.4-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown bacula:adm /var/log/bacula chmod 750 /var/log/bacula --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606596: binkd: affected by privilege escalation vulnerability in logrotate
Package: binkd Version: 0.9.9+rel-2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R ftn:adm /var/log/binkd/ --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606599: mrtg: affected by privilege escalation vulnerability in logrotate
Package: mrtg Version: 2.16.2-4 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod 750 /var/log/mrtg --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606600: pyicqt: affected by privilege escalation vulnerability in logrotate
Package: pyicqt Version: 0.8.1.3-2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R pyicqt:adm /var/log/pyicqt --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606598: net-acct: affected by privilege escalation vulnerability in logrotate
Package: net-acct Version: 0.71-8 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod 755 /var/log/net-acct chown root:root /var/log/net-acct --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606601: mysql-server-5.0: affected by privilege escalation vulnerability in logrotate
Package: mysql-server-5.0 Version: 5.0.51a-24+lenny1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R mysql:adm $mysql_newlogdir;chmod 2750 $mysql_newlogdir; chown mysql:adm $mysql_logdir/mysql.$i chmod 0640$mysql_logdir/mysql.$i --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606602: lighttpd: affected by privilege escalation vulnerability in logrotate
Package: lighttpd Version: 1.4.23-3 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown www-data:www-data /var/log/lighttpd /var/run/lighttpd chmod 0750 /var/log/lighttpd /var/run/lighttpd --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606597: tinyhoneypot: affected by privilege escalation vulnerability in logrotate
Package: tinyhoneypot Version: 0.4.6-8 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R $NUSER:root /var/log/thpot chmod -R o-rwX /var/log/thpot --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606608: squid: affected by privilege escalation vulnerability in logrotate
Package: squid Version: 2.7.STABLE6-2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown $usr:$grp /var/log/squid -R --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606609: icecast2: affected by privilege escalation vulnerability in logrotate
Package: icecast2 Version: 2.3.2-3 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R icecast2: /var/log/icecast2 /etc/icecast2 --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606541: zabbix-server-mysql: affected by privilege escalation vulnerability in logrotate
Package: zabbix-server-mysql Version: 1.6.5-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown zabbix:zabbix /var/log/zabbix-server -R --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate
Package: clamav-freshclam Version: 0.95.2+dfsg-4 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod 640 $FRESHCLAMLOGFILE chown $dbowner:adm $FRESHCLAMLOGFILE --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606544: postgresql-common: affected by privilege escalation vulnerability in logrotate
Package: postgresql-common Version: 100 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod 1775 /var/log/postgresql chown root:postgres /var/log/postgresql --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606545: polipo: affected by privilege escalation vulnerability in logrotate
Package: polipo Version: 1.0.4-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod -R 640 $LOG_DIR chown proxy:adm $LOG_DIR chmod 2755 $LOG_DIR --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606547: mathopd: affected by privilege escalation vulnerability in logrotate
Package: mathopd Version: 1.5p6-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R www-data:www-data /var/log/mathopd --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606548: pymsnt: affected by privilege escalation vulnerability in logrotate
Package: pymsnt Version: 0.11.3-4 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R pymsnt:adm /var/log/pymsnt --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606549: bayonne: affected by privilege escalation vulnerability in logrotate
Package: bayonne Version: 2.3.2-3+b2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R bayonne /var/log/bayonne --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606551: ejabberd: affected by privilege escalation vulnerability in logrotate
Package: ejabberd Version: 2.0.5-1.1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown ejabberd:adm /var/log/ejabberd chmod 750 /var/log/ejabberd --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606552: flumotion: affected by privilege escalation vulnerability in logrotate
Package: flumotion Version: 0.4.2-3.1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown flumotion:adm /var/log/flumotion --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606553: conserver-server: affected by privilege escalation vulnerability in logrotate
Package: conserver-server Version: 8.1.16-3 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R conservr:adm /var/log/conserver /var/run/conserver.pid chmod 750 /var/log/conserver chown -R root:root /var/log/conserver /var/run/conserver.pid chmod 750 /var/log/conserver --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606554: aolserver4: affected by privilege escalation vulnerability in logrotate
Package: aolserver4 Version: 4.5.0-16.1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R www-data:www-data $LOGDIR chmod 755 $LOGDIR --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606555: qwik: affected by privilege escalation vulnerability in logrotate
Package: qwik Version: 0.8.4.4-0.1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown qwik:qwik /var/log/qwik/ /var/cache/qwik/ /var/run/qwik/ --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606560: pyaimt: affected by privilege escalation vulnerability in logrotate
Package: pyaimt Version: 0.8a-9 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R pyaimt:adm /var/log/pyaimt --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606561: zabbix-agent: affected by privilege escalation vulnerability in logrotate
Package: zabbix-agent Version: 1.6.5-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown zabbix:zabbix /var/log/zabbix-agent -R --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606562: zabbix-server-pgsql: affected by privilege escalation vulnerability in logrotate
Package: zabbix-server-pgsql Version: 1.6.5-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown zabbix:zabbix /var/log/zabbix-server -R --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606563: mumble-server: affected by privilege escalation vulnerability in logrotate
Package: mumble-server Version: 1.1.8-2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod 0750 /var/log/mumble-server chown mumble-server:adm /var/log/mumble-server --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606566: cacti: affected by privilege escalation vulnerability in logrotate
Package: cacti Version: 0.8.7d-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod 0640 /var/log/cacti/rrd.log /var/log/cacti/cacti.log chown -R www-data.www-data /var/log/cacti/ --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606567: ecartis: affected by privilege escalation vulnerability in logrotate
Package: ecartis Version: 1.0.0+cvs.20030911-11 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R $UNAME:$UNAME /var/lib/ecartis /var/log/ecartis.log --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606568: cherokee: affected by privilege escalation vulnerability in logrotate
Package: cherokee Version: 0.99.20-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown $RUNAS_USER $LOGFILE chown $RUNAS_USER $LOGDIR --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606569: couchdb: affected by privilege escalation vulnerability in logrotate
Package: couchdb Version: 0.9.0-2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R couchdb:couchdb /var/log/couchdb chmod -R 0770 /var/log/couchdb --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606570: privoxy: affected by privilege escalation vulnerability in logrotate
Package: privoxy Version: 3.0.12-2 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R privoxy:adm /var/log/privoxy chmod 750 /var/log/privoxy --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606571: debtorrent: affected by privilege escalation vulnerability in logrotate
Package: debtorrent Version: 0.1.9 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R debtorrent:debtorrent /var/log/debtorrent chmod -R 775 /var/log/debtorrent --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606572: speech-dispatcher: affected by privilege escalation vulnerability in logrotate
Package: speech-dispatcher Version: 0.6.7-4 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R $USER_NAME /var/log/speech-dispatcher --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606573: slony1-bin: affected by privilege escalation vulnerability in logrotate
Package: slony1-bin Version: 1.2.16-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown postgres:postgres /var/log/slony1/ chmod 2770 /var/log/slony1/ --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606580: squid3: affected by privilege escalation vulnerability in logrotate
Package: squid3 Version: 3.0.STABLE18-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R $usr:$grp $log_dir --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606581: tor: affected by privilege escalation vulnerability in logrotate
Package: tor Version: 0.2.1.19-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- find /var/log/tor \( \( ! -user debian-tor \) -o \( ! -group adm \) \) -print0 | xargs -0 --no-run-if-empty chown debian-tor:adm find /var/log/tor -type d -print0 | xargs -0 --no-run-if-empty chmod 02750 find /var/log/tor -type f -print0 | xargs -0 --no-run-if-empty chmod 00640 --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606582: mserv: affected by privilege escalation vulnerability in logrotate
Package: mserv Version: 0.35-6.4 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R mserv:mserv /var/log/mserv/ --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606583: cricket: affected by privilege escalation vulnerability in logrotate
Package: cricket Version: 1.0.5-10 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown cricket /var/lib/cricket /var/log/cricket /etc/cricket/config \ --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606584: dansguardian: affected by privilege escalation vulnerability in logrotate
Package: dansguardian Version: 2.10.1.1-1 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown -R dansguardian:dansguardian /var/log/dansguardian chmod -R u+wr /var/log/dansguardian chmod u+wrx /var/log/dansguardian --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606585: sks: affected by privilege escalation vulnerability in logrotate
Package: sks Version: 1.1.0-8 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chmod -R g+rX /var/log/sks chmodg+s /var/log/sks chmod -R g+rX /var/log/sks chmodg+s /var/log/sks --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606586: sbnc: affected by privilege escalation vulnerability in logrotate
Package: sbnc Version: 1.2-15 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown sbnc:adm /var/log/sbnc chmod 0740 /var/log/sbnc --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606587: epos: affected by privilege escalation vulnerability in logrotate
Package: epos Version: 2.5.37-8 Severity: grave Justification: privilege escalation vulnerability Tags: security There was a privilege escalation vulnerability in logrotate that I reported about four years ago and which finally got fixed in testing rouhgly one year ago (see bug #388608). In lenny this vulnerability still exists and logrotate's maintainer doesn't seem to be interested in fixing it, given that nothing of substance has happened since when I last notified him of the problem about two weeks ago. As a proof of concept, I did successfully use it to elevate my privileges from the postgres user to root. As it affects packages where the log directory is writable for the package's system user, I based this mass filing on a rough analysis of maintainer scripts, avoiding the effort of actually installing and testing each individual package. These lines from this package's maintainer scripts suggest that it likely is affected by the vulnerability: --- chown epos $LOG_DIR --- Please note that the analysis this mass filing is based on also is roughly a year old, and anyhow I don't recall which debian suite I based it on at that time--as such, this report may be against the wrong version and otherwise outdated in some details. Given how much effort I have already needlessly put into this, I hope you have some understanding for me not polishing this bug report. Primarily I am filing this bug in order to allow the maintainers of packages using logrotate to work around logrotate if they deem that necessary. Also, you should note that the security fix in testing introduces a regression that may also affect this package which could cause data loss in situations where this couldn't happen before. A fix for this regression is available to logrotate's maintainer, also still unapplied for over a year. A mass filing against packages affected by that regression may follow later. For some further details please see my announcement of this mass filing on debian-qa: http://lists.debian.org/debian-qa/2010/11/msg00024.html I would also suggest to use that thread for any further discussion that is not specific to this package and possibly for coordination between maintainers of affected packages in order to avoid duplicated efforts where possible. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556939: libgfshare-bin: reconstruction results in garbage
Package: libgfshare-bin Version: 1.0.2-1 Severity: critical Well, the subject basically says it all. Severity critical as even the package description suggests using it for cryptographic keys, which the access to large amounts of data can depend on, in which case the inability to reconstruct the key could result in massive data loss. Test case: while :; do mkdir 8ec81f75-3bc9-4b95-812d-41ca28365aad || exit 1 echo | gfsplit /dev/stdin 8ec81f75-3bc9-4b95-812d-41ca28365aad/x rm `ls 8ec81f75-3bc9-4b95-812d-41ca28365aad/x.* | tail -2` [ `gfcombine -o /dev/stdout 8ec81f75-3bc9-4b95-812d-41ca28365aad/x.* | md5sum` = '68b329da9893e34099c7d8ad5cb9c940 -' ] echo OK || echo ERR rm -rf 8ec81f75-3bc9-4b95-812d-41ca28365aad sleep 1 done -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556939: libgfshare-bin: can produce broken shares containing foo.000
Hi, On Wed, Nov 18, 2009 at 03:36:37PM +0100, Florian Zumbiehl wrote: Why is it randomized anyhow? Just numbering shares from 1 would produce more reproducible results, thus making it more likely that problems specific to a certain use case would get noticed before it's too late. It probably would be easier to use for some purposes, too, if file names were easier to predict. Randomised so that you can easily strip the numbers and place them elsewhere and thereby make it harder to guess the share numbers. And that is good for what? Florian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556939: libgfshare-bin: can produce broken shares containing foo.000
Hi, One thing that the two failures had in common is that component x.000 was produced and was used to remake the share; with the default 3-of-5 setting, this can be expected to happen in around 2% of calls to gfsplit. That indeed seems to fit my observations. The mathematics of Shamir secret sharing do not work correctly with x_i = 0, i.e. a component foo.000, so the library should reject any sharenrs array that contains 0, and the utilities should not produce such arrays. I'll prepare a patch this evening. Why is it randomized anyhow? Just numbering shares from 1 would produce more reproducible results, thus making it more likely that problems specific to a certain use case would get noticed before it's too late. It probably would be easier to use for some purposes, too, if file names were easier to predict. BTW, the command line parser is pretty much completely broken if you judge it by the error messages it produces even for completely valid values as per its own help output. In case you want to fix that, too ... Florian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#467518: git-core: builds defective package under umask 077
Package: git-core Version: 1:1.5.4.2-1~bpo40+1 Severity: serious Justification: no longer builds from source Well, when starting the build from a umask 077 environment, numerous files in the resulting package are 0600, which makes it mostly unusable. I have not explicitly tested whether this applies to the non-backport version, too, but I don't see any reason why that should differ for a backported package. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages git-core depends on: ii cpio 2.6-18GNU cpio -- a program to manage ar ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libcurl3-gnutls7.15.5-1etch1 Multi-protocol file transfer libra ii libdigest-sha1-perl2.11-1NIST SHA-1 message digest algorith ii liberror-perl 0.15-8Perl module for error/exception ha ii libexpat1 1.95.8-3.4XML parsing C library - runtime li ii perl-modules 5.8.8-7etch1 Core Perl modules ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages git-core recommends: ii curl 7.15.5-1etch1 Get a file from an HTTP, HTTPS, FT ii less 394-4 Pager program similar to more ii openssh-client [ssh-client 1:4.3p2-9 Secure shell client, an rlogin/rsh ii patch 2.5.9-4 Apply a diff file to an original ii rsync 2.6.9-2etch1 fast remote file copy program (lik -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319348: hylafax-server: faxq handles faxsend exit status incorrectly
Package: hylafax-server Version: 1:4.2.1-5 Severity: grave Justification: renders package unusable faxq processes the signal by which the faxsend process was killed as the exit status rather than the actual exit status. For example, removing /usr/sbin/faxsend causes these log messages: | Jul 21 13:54:36 florz FaxQueuer[3352]: JOB 32 (active dest 9 pri 127 tts 0:00 killtime 2:58:22): CMD START /usr/sbin/faxsend -m blah sendq/q32 (PID 3368) | Jul 21 13:54:46 florz FaxQueuer[3352]: JOB 32 (active dest 9 pri 127 tts 0:00 killtime 2:58:12): CMD DONE: exit status 0 ... where, according to the source, 127 should be the actual exit status. Also, when replacing the faxsend program with anything that exits with some different status like the ones listed in man faxsend, the log says that the exit status was 0. However, when doing a kill of itself in that program, for example with signal 9, the result looks like this: | Jul 21 13:48:06 florz FaxQueuer[31262]: JOB 27 (active dest 9 pri 127 tts 0:00 killtime 2:59:00): CMD START bin/blahfaxsend -m blah sendq/q27 (PID 2947) | Jul 21 13:48:06 florz FaxQueuer[31262]: JOB 27 (active dest 9 pri 127 tts 0:00 killtime 2:59:00): CMD DONE: exit status 0x9 As faxq decides by that exit status how to further process the job, and in particular exit status 2, which won't be recognized, according to man faxsend, indicates successful completion, I guess this makes the package mostly unusable for anyone (yes, I indeed do wonder why there is no bug report on this yet, which is why I even completely reinstalled hylafax-server from a different source - the problem is still there ...). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.31 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages hylafax-server depends on: ii debconf 1.4.30.13 Debian configuration management sy ii gawk [awk] 1:3.1.4-2 GNU awk, a pattern scanning and pr ii gs 8.01-5 Transitional package ii gs-gpl [gs] 8.01-5 The GPL Ghostscript PostScript int ii hylafax-client 1:4.2.1-5 Flexible client/server fax softwar ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13 GCC support library ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3 ii libtiff-tools3.7.2-3 TIFF manipulation and conversion t ii libtiff4 3.7.2-3 Tag Image File Format (TIFF) libra ii mailx1:8.1.2-0.20040524cvs-4 A simple mail user agent ii mawk [awk] 1.3.3-11a pattern scanning and text proces ii mime-codecs 7.19-4 Fast Quoted-Printable and BASE64 M ii psmisc 21.5-1 Utilities that use the proc filesy ii sed 4.1.2-8 The GNU sed stream editor ii zlib1g 1:1.2.2-4.sarge.1 compression library - runtime -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319348: Acknowledgement (hylafax-server: faxq handles faxsend exit status incorrectly)
Meanwhile, I investigated the problem a bit more and it seems that it's mostly a matter of misleading/wrong documentation rather than an actual major bug in the software. (1) faxq apparently completely ignores the exit status of faxsend as long as it didn't terminate due to a signal but instead looks at the returned:-field in the queue-file and (2) what is written to the log is not the pure exit status but rather the whole status integer as returned by wait(). Apart from the remaining bug that a failed exec() isn't recognized as such, I'd suggest the following changes in order to avoid others misunderstanding this, too: 1. in man faxsend, replace: faxsend returns the new job status to faxq through the exit(2) return value of the process by: faxsend returns the new job status through the exit(2) return value of the process--however, faxq ignores this and instead reads the same value from the returned:-filed in the queue file 2. and in man sendq: returned Used internally to determine the last return value of the send command issued for this job. by: returned Used internally to determine the last return value of the send command issued for this job. The faxsend program is responsible for putting that value here, as faxq actually ignores its exit status. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302421: links-ssl: handles line breaks in link URLs incorrectly
Package: links-ssl Version: 0.96.20020409-2 Severity: grave Tags: security Justification: user security hole Hi, put this into an HTML file: a href=http://localhost:12345/blah.php#10;Host:blurgl.tld#10;X-Blub:;a/a when using that link, links-ssl (I guess that this applies to links without ssl, too) will generate the following request to localhost, port 12345: | GET /blah.php | Host:blurgl.tld | X-Blub: HTTP/1.1 | Host: localhost:12345 | User-Agent: ELinks (0.4pre5; Linux 2.4.27 i686; 132x60) | Accept: */* | Connection: Keep-Alive Apart from the fact that this shouldn't happen, I could imagine at least this particular scenario to be used in an attack: On a sufficiently permissive HTTP server that allows the protocol version field to be missing and that accepts the first Host: header as the significant one, this could lead to cookies belonging to localhost:12345 getting into the hands of the virtual host blurgl.tld on the same server. Cya, Florian -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux florz 2.4.27 #3 Sat Aug 28 04:55:31 CEST 2004 i686 Locale: LANG=C, [EMAIL PROTECTED] Versions of packages links-ssl depends on: ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an ii libgpmg11.19.6-12General Purpose Mouse Library [lib ii liblua404.0-4Main interpreter library for the L ii liblualib40 4.0-4Extension library for the Lua prog ii libssl0.9.6 0.9.6c-2.woody.7 SSL shared libraries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
