Re: FWD: Squirrelmail XSS + SQL security bug?
Hi Jeroen, Sam, could you please forward you incoming mail about security issues to someone who has more time to look into it? Well, I wouldn't lose time doing so. Better to upgrade to latest 1.4.3a. Yes, contrary to the Debian backporting policy, but in this case there are sufficient reasons to make the exception (and it's less intrusive than completely removing SM from Woody, as I listened before). I wouldn't trust an old 1.2.6 version; not without some guarantees than SM team would provide a detailed info of applied security fixes. And that's not the case, as stated by Matt. In this case, I agree with him: SM team should make a little effort to document such bugs instead of silently patching. I told this to SM developpers when I contacted them one month ago. Security through obscurity is not good at all. I disclosed in a _detailed way_ several bugs: [RS-2004-1] http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt This wasn't reported in the Debian BTS. I was unaware of Debian BTS when I reported the vuln. Anyway, it should be sufficient to notify it to security email address. People who reports security bugs doesn't necesarily need to know about bug tracking systems or the way a vendor archives or deals with a reported bug. Moreover, security teams should monitorize public security mailing-lists like Bugtraq. So if the usual communication channels fail (for instance, e-mail to security address), at least you are aware of public vulns) (and then you can feed your internal / external BTS, or act as whatever you want). I (the person uploading that version) was not aware of this, partly because you didn't file a bug in the BTS about this. Note however that As I have told, to file a bug is not my duty (although I would have made it if I had known of BTS' existence). I reported the bug to SM developpers (_before_ making it public, that's important, and letting sufficient time for the bug to be fixed) and also to Debian maintainer _as a courtesy_ (I don't have the time nor resources to notify all distros which use SM; I did the exception with Debian because I use Debian and I like it). - I don't know whether or not the old XSS bugs which I reported to affect Debian Woody (read RS-2004-1) are still uncovered. I'm afraid it is... Thanks for the direct pointer, I assume you did contact [EMAIL PROTECTED] about this? I should check my outbox to verify this (I think I placed [EMAIL PROTECTED] in cc). In all cases: - You can assume _at least_ Debian maintainer (Sam) was notified. - I recall to have talked about this with Matt, so I assume he is / was also aware of this. Indeed he replied in a public mailing-list to my advisory post so he should read it: http://seclists.org/lists/fulldisclosure/2004/Jun/0029.html Also, statements like this won't help you very much if you want a serious resonse: | Please, learn the lesson and repeat with me: Debian stable software | is not always as secure as we usually thought. Oddly enough, Debian | unstable was free of these bugs :-) This is my personal opinion and I'm free to think like this. I'm not imposing anything. But Debian unstable keeps getting lots of other bugs, so is often no alternative :) Well, from security perspective I prefer unstable. Same applies to usability perspective (I don't like outdated versions of certain software). Again this is my personal opinion. I respect Debian Woody policy but I don't support it. Better not to speak about this (flame-war risk! :-)). If Debian isn't notified of security bugs, they can't fix them. Weird Don't blame me. Your statement is easily refutable: If Debian maintainers don't answer to important mails (I know the email address was fine because I previosly had contacted Sam using the same method; and I insisted trying to re-contact) and Debian security team is unaware of public security mailing-lists (or they answer to certain threads without reading the original post :-?) it's not my fault. Please, don't start the war. I'm only defending my position :) that you here claim unstable was free of these bugs, while above you claim Debian unstable _had_ these bugs at the time of your advisory. So, which one of the two is it? Or are there more issues involved than the ones detailed in RS-2004-1? Please, read my adv with more attention. Let's quote from it: * From summary part: A vulnerability has been discovered in SM... --- This is the NEW bug. As a side effect of my research I discovered that older known SM flaws were still present in latest Debian stable (Woody) package. I will also discuss them here (there is no need to issue another advisory only for that ;-)). But _please note_ that if I don't explicitly mention it, I will always be referring to the new (and recently discovered) bug. --- I mention the old bugs too and clearly referred to Woody. * From Affected versions: The (new) bug could be reproduced with latest version of SM (both stable and devel branchs) (*). In particular: -
Re: FWD: Squirrelmail XSS + SQL security bug?
On Tue, Jul 06, 2004 at 12:47:21PM +0200, Rom?n Medina wrote: Hi Jeroen, Sam, could you please forward you incoming mail about security issues to someone who has more time to look into it? Well, I wouldn't lose time doing so. Better to upgrade to latest 1.4.3a. Yes, contrary to the Debian backporting policy, but in this case there are sufficient reasons to make the exception (and it's less intrusive than completely removing SM from Woody, as I listened before). I wouldn't trust an old 1.2.6 version; not without some guarantees than SM team would provide a detailed info of applied security fixes. And that's not the case, as stated by Matt. In this case, I agree with him: SM team should make a little effort to document such bugs instead of silently patching. I told this to SM developpers when I contacted them one month ago. Security through obscurity is not good at all. I agree with what you say about the SM team, as much as getting a cc/forward of commit mails that fix a security issue, would already be great. Simply putting a new major upstream release (1.4.x instead of 1.2.x) won't be accepted for a security update, and also because XSS issues are not that a severe issue, I don't think there is any reason to remove 1.2.x from woody. Those XSS, and especially the SQL injection needs to be fixed though. Thanks for your very detailed mail, I'll look into it w.r.t. remaining woody issues. I also saw three CVE's assigned to squirrelmail in 2004, none of them have been patched by Debian. I'll trace that down. I disclosed in a _detailed way_ several bugs: [RS-2004-1] http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt This wasn't reported in the Debian BTS. I was unaware of Debian BTS when I reported the vuln. Anyway, it should be sufficient to notify it to security email address. People who reports security bugs doesn't necesarily need to know about bug tracking systems or the way a vendor archives or deals with a reported bug. Moreover, security teams should monitorize public security mailing-lists like Bugtraq. So if the usual communication channels fail (for instance, e-mail to security address), at least you are aware of public vulns) (and then you can feed your internal / external BTS, or act as whatever you want). I fully agree with you, sorry, I didn't intend to 'blame' you for not reporting it in the BTS. It would have made things easier/go faster, but I agree, it is by no means your fault it didn't happen. It'd be appreciated if you could do so though. I (the person uploading that version) was not aware of this, partly because you didn't file a bug in the BTS about this. Note however that As I have told, to file a bug is not my duty (although I would have made it if I had known of BTS' existence). I reported the bug to SM developpers (_before_ making it public, that's important, and letting sufficient time for the bug to be fixed) and also to Debian maintainer _as a courtesy_ (I don't have the time nor resources to notify all distros which use SM; I did the exception with Debian because I use Debian and I like it). Then the problem was with Debian internally, that this wasn't forwarded/fixed... again, sorry for insinuating you should have filed a bug :) - I don't know whether or not the old XSS bugs which I reported to affect Debian Woody (read RS-2004-1) are still uncovered. I'm afraid it is... Thanks for the direct pointer, I assume you did contact [EMAIL PROTECTED] about this? I should check my outbox to verify this (I think I placed [EMAIL PROTECTED] in cc). In all cases: - You can assume _at least_ Debian maintainer (Sam) was notified. ... - I recall to have talked about this with Matt, so I assume he is / was also aware of this. Indeed he replied in a public mailing-list to my advisory post so he should read it: http://seclists.org/lists/fulldisclosure/2004/Jun/0029.html I don't know what happened to this. In answer to this question of yours: http://seclists.org/lists/fulldisclosure/2004/Jun/0046.html | | #ifdef _security_perspective_ | #define usual_channels bugtraq other_lists | #endif | #ifdef _devel_perspective_ | #define usual_channels changelog_file | #endif | printf(My usual channels are: %s, usual_channels); | | It was some kind of pseudocode :-) Question: which perspective are | using Debian maintainers to monitorize their packages? In the | particular case of SM, the old XSS issues were listed in ChangeLog, | but .deb package was not updated. Why? Debian maintainers should monitor upstream, especially changelogs of new versions, and preferable also upstream devel mailinglists. The .deb package was not updated because the Debian maintainer for squirrelmail was too busy, why the security team didn't update woody yet, maybe they were too busy too. I have a suggestion how to potentially improve this, I'll send a separate mail about it. But Debian unstable keeps getting lots of other
Re: Bug#257165: udev: input device permissions
Quoting Itay Ben-Yaacov ([EMAIL PROTECTED]): Now, people using sid accept the potential consequences, but the consequences for sarge should be somewhat lesser... Actually, the consequences for sarge (while it's still the testing branch) will tend generally to be somewhat _greater_ than for sid, since it benefits from neither guaranteed Security Team support (stable branch) nor from immediate release of maintainer uploads (unstable branch). Anyone who runs the testing branch implicitly undertakes to stay on top of needed security updates via whatever manual administrative oversight works for that sysadmin's local system. Caveat user. -- Cheers, Transported to a surreal landscape, a young girl kills the first Rick Moen woman she meets, and then teams up with three complete strangers [EMAIL PROTECTED] to kill again. -- Rick Polito's That TV Guy column, describing the movie _The Wizard of Oz_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposal/suggestion for security team w.r.t. published vulerabilities
Hi, As I promised in [1], a suggestion for the Debian security team. Since the security team is generally very busy sorting out any kind of vulnerability, sometimes fixes can take a little bit longer than usual, especially if the impact is relatively low. Taking the Social Contracts 'We will not hide problems', and those vulerabilities that have already been made public, I think it'd be a good idea if the security team, once a vulnerability is already made public, for example via a Bugtraq or something, or some other vendor/upstream announced it, files a bug (tag woody usually I guess) in the BTS about it. There is no longer reason to hide the problem, i.e., keep it away from the BTS once it is published. This also enables other people to 1) see there is a security defect in that package in woody 2) help solving it by adding patches, so the security team only has to check the patches As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all three not yet solved in woody, but also not filed in the BTS (hm, two of them directly refer to a patch[2][3] solving it...). Therefore, I'd like to ask the security team to file grave bugs with security+woody on packages for which a vulnerability has been made public, and a security announcement isn't nearly-ready. I can't imagine this would interfere too much with the issue tracker or whatever the security team internally uses to track issues. Or is there some reason filing bugs like I described here isn't wanted? --Jeroen [1] http://lists.debian.org/debian-security/2004/07/msg00030.html [2] http://marc.theaimsgroup.com/?l=squirrelmail-cvsm=108532891231712 [3] http://marc.theaimsgroup.com/?l=squirrelmail-cvsm=108309375029888 -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all three not yet solved in woody, but also not filed in the BTS (hm, two of them directly refer to a patch[2][3] solving it...). Go ahead and file the bug. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 03:08:38PM -0400, Michael Stone wrote: On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all three not yet solved in woody, but also not filed in the BTS (hm, two of them directly refer to a patch[2][3] solving it...). Go ahead and file the bug. mdz told me this isn't done for practical reasons: the BTS isn't very suitable for tracking which versions are affected, and a sid upload can close such a bug while it's still in woody. While I think it'd still be possible without too much hassle, if they don't want to do so, I'm not going to interfere in that. For those two bugs, I'm simply mailing the security team myself, maybe also file a bug, don't know yet. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 09:13:18PM +0200, Jeroen van Wolffelaar wrote: On Tue, Jul 06, 2004 at 03:08:38PM -0400, Michael Stone wrote: On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all three not yet solved in woody, but also not filed in the BTS (hm, two of them directly refer to a patch[2][3] solving it...). Go ahead and file the bug. mdz told me this isn't done for practical reasons: the BTS isn't very suitable for tracking which versions are affected, and a sid upload can close such a bug while it's still in woody. While I think it'd still be possible without too much hassle, if they don't want to do so, I'm not going to interfere in that. For those two bugs, I'm simply mailing the security team myself, maybe also file a bug, don't know yet. You are free to file a bug, and sometimes this helps to get a response from the maintainer; just note that these bugs will generally not be used by the security team for tracking the status of the vulnerabilities. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
In article [EMAIL PROTECTED] you wrote: mdz told me this isn't done for practical reasons: the BTS isn't very suitable for tracking which versions are affected, and a sid upload can close such a bug while it's still in woody. While I think it'd still be possible without too much hassle, if they don't want to do so, I'm not going to interfere in that. Well, I guess anybody is free to open bugs against packages if they hear about vulnerabilities. I guess this even might help in some cases. But I dont think security team can publish received vendor alerts before going public date. Effectively this is hiding, but on the other hand it is also respecting the wishes and requests of others. And not honoring them will quickly lead to debian beeing cut-off from those alerts. So thats why unpublished alerts are not posted. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 10:39:09PM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: mdz told me this isn't done for practical reasons: the BTS isn't very suitable for tracking which versions are affected, and a sid upload can close such a bug while it's still in woody. While I think it'd still be possible without too much hassle, if they don't want to do so, I'm not going to interfere in that. Well, I guess anybody is free to open bugs against packages if they hear about vulnerabilities. I guess this even might help in some cases. But I dont think security team can publish received vendor alerts before going public date. Effectively this is hiding, but on the other hand it is also respecting the wishes and requests of others. And not honoring them will quickly lead to debian beeing cut-off from those alerts. So thats why unpublished alerts are not posted. I'm only talking about published issues, of course, unpublished ones shouldn't go into the BTS. Having the security team file bugs for _published_ issues, will make part of the work of the security team, managing which vulernabilities exist and apply to woody, and aren't fixed yet, also available to non-security team members, who then can possibly more effectively help on security issues. I'll post a list of a few of such issues here later tonight, that are exactly issues that could have been filed in the BTS. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#257165: udev: input device permissions
Rick Moen wrote: Quoting Itay Ben-Yaacov ([EMAIL PROTECTED]): Now, people using sid accept the potential consequences, but the consequences for sarge should be somewhat lesser... Actually, the consequences for sarge (while it's still the testing branch) will tend generally to be somewhat _greater_ than for sid, since it benefits from neither guaranteed Security Team support (stable branch) nor from immediate release of maintainer uploads (unstable branch). Anyone who runs the testing branch implicitly undertakes to stay on top of needed security updates via whatever manual administrative oversight works for that sysadmin's local system. Caveat user. Hi 1- Why if Itay, find a solution for the problem we had, doesn't it offer his solution to the community ; ethen, if he is on a single user machine ? 2 - Sorry, it's maybee a naive question, but as new Debian user, i'm very well-willing in the way or the Debian Free spirit tend to work :) ! 3 - Don't be upset, if i'm wrong :(! Note - I'm personnaly on an upgraded Knoppix 3.2, then sid.., to an almost sarge now, but considered - maybee am'i wrong ? - to be still a 'testing'... ? Everything works very fine, for instance and i'm realy positively astonished of it's 'stability'... :) ! And i first used a Mandrake, form The 7. to the 9.1., if you see what i mean about the 'spirit' ? So, thanks for all the works you are doing andd soon maybee shall'i bee helpfull for something, out of translations ? Sheers Mi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: Hi, As I promised in [1], a suggestion for the Debian security team. Since the security team is generally very busy sorting out any kind of vulnerability, sometimes fixes can take a little bit longer than usual, especially if the impact is relatively low. Funny, you are observing that the security team is overworked and you suggest adding Yet Another Thing To Do (tm) to their list. Therefore, I'd like to ask the security team to file grave bugs with security+woody on packages for which a vulnerability has been made public, and a security announcement isn't nearly-ready. I can't imagine this would interfere too much with the issue tracker or whatever the security team internally uses to track issues. Why does the security team have to do this? Anybody can do it. BTS reports can serve as a reminder or as a way to inform both the maintainer and the security team for known vulnerabilities. It also helps users who might track bugs related to woody and, even now in a time close to release, it might help track bugs in sarge so that we don't ship a new release with software that includes security vulnerabilities. Actually, the security team will probably appreciate bug submitters to do the following: 1.- include a CVE name (in order to discriminate vulnerabilities to previous ones). After all we _are_ CVE compatible (almost all DSAs include CVE names) 2.- tag the bug based on the version that is vulnerable (woody, sarge, sid, or all/some of them). Sometimes you might need to actually check out the code to see if the version in stable is vulnerable. 3.- provide a patch for the stable release I know that the security team will probably appreciate if all this work is done for publicly known vulnerabilities. A bug submitter should make an effort (if he wants to help out the security team and not hinder it) to provide more info than just a Bugtraq post (which are in many cases incomplete or are simply not correct/true/relevant). He should also made an effort to review http://www.debian.org/security/nonvulns-woody and see if the issue has already been determined _not_ to affect woody. Or is there some reason filing bugs like I described here isn't wanted? None I know of. Actually, there are bugs open in the BTS tagged 'security' that might get a DSA when the security team finds the time to do it. There are priorities regarding which packages should get DSAs first and there are some packages, like the kernel, which are not that easy to publish DSAs for. The security team will probably appreciate people giving a hand in debugging these issues in detail (as opposed to just forwarding a Bugtraq mail) Regards Javier PS: I don't imply that I do this myself correctly every time, I've probably reported security bugs incorrectly a number of times, these are just some good practice guidelines I believe bug submitters should adhere to. signature.asc Description: Digital signature
Re: Bug#257165: udev: input device permissions
Quoting Mezig ([EMAIL PROTECTED]): 1- Why if Itay, find a solution for the problem we had, doesn't it offer his solution to the community ; ethen, if he is on a single user machine ? That would be good. I was only addressing Itay's assertion that the consequences for sarge should be somewhat lesser. That turns out not to be the case (for now, while sarge = testing). Note - I'm personnaly on an upgraded Knoppix 3.2, then sid.., to an almost sarge now, but considered - maybee am'i wrong ? - to be still a 'testing'... ? Knoppix at any given point appears to be not-quite-sid, with maybe 10% stable and 10% Something Else Entirely. (I applaud your enthusiasm, and don't mean to denigrate what you're using. I'm just trying to describe it accurately.) -- Cheers, Founding member of the Hyphenation Society, a grassroots-based, Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed, [EMAIL PROTECTED] modern-American-English-usage-improvement association. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 11:51:21PM +0200, Jeroen van Wolffelaar wrote: security issues. I'll post a list of a few of such issues here later tonight, that are exactly issues that could have been filed in the BTS. If you really have so much time I'm sure you can find better things to do than post lists of things that could have been filed in the BTS. Such as, for example, filing a patch in the BTS? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
