Proposed mass prototypejs bug filing for multiple security issues
Hi, The prototypejs script has been found to be vulnerable to a couple security issues [0],[1]. This script is embedded in about 32 other packages and I would like to file bugs against all of those that are affected. Since this would probably be considered a mass filing, I am running it past -devel first. I intend to send the following two bug reports for each vulnerable package; one bug on the vulnerabilities themselves and the other bug asking for the maintainer to switch to the system/shared prototypejs. I will fill in affected version numbers (Y.Y.Y) on a per-package basis. Let me know if this is OK, and whether there is anything else I should be aware of. Here are the affected source packages: - auth2db unfixed (embed) - webcit unfixed (embed) - asterisk unfixed (embed) - doc-iana unfixed (embed) - libaws unfixed (embed) - libgettext-ruby unfixed (embed) - libjson-ruby unfixed (embed) - lucene2 unfixed (embed) - libopenid-ruby unfixed (embed) - solr unfixed (embed) - glpi unfixed (embed) - mnemo2 unfixed (embed) - nag2 unfixed (embed) - knowledgeroot unfixed (embed) - mediatomb unfixed (embed) - mt-daapd unfixed (embed) - op-panel unfixed (embed) - ebug-http unfixed (embed) - phpgedview removed (embed) - poker-network unfixed (embed) - webhelpers unfixed (embed) - qwik unfixed (embed) - rails unfixed (embed) - typo3-src unfixed (embed) - wordpress 2.5.0-2 (embed) - zope unfixed (embed) - smokeping unfixed (embed) - ampache 3.4.1-2 (embed) - exaile unfixed (embed) - hobix unfixed (embed) - pixelpost unfixed (embed) - symfony unfixed (embed) - zabbix unfixed (embed) - turba2 unfixed (embed) Mike - package: auth2db version: 0.2.5-2+dfsg-1 severity: serious tags: security Hi, Your package contains an embedded version of prototypejs that is vulnerable to either CVE-2007-2383 (affecting prototypejs 1.5.1 and earlier) [0], CVE-2008-7220 (affecting prototypejs 1.6.0.2 and earlier) [1], or both. Your package embeds prototypejs version Y.Y.Y and is affected [only by CVE-2007-2383 / only by CVE-2008-7220 / by both issues]. This is a mass-filing, and the only checking done so far is a version comparison, so please determine whether or not your package is itself affected or not. If it is not affected please close the bug with a message indicating this along with what you did to check. The version of your package specified above is the earliest version with the affected embedded code. If this version is in one or both of the stable releases and you are affected, please coordinate with the release team to prepare a proposed-update for your package to stable/oldstable. If you correct the problem in unstable, please make sure to include the CVE number in your changelog. Thank you for your attention to this problem. Mike [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2383 [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7220 - package: auth2db version: 0.2.5-2+dfsg-1 severity: important tags: security Hi, Your package embeds prototypejs version X.X.X, which makes security updates very cumbersome, difficult, and potentially error-prone. Please update your package to make use of the system prototypejsb provided by the prototypejs package. Thank you very much for your attention on this matter. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On 9/18/09, Patrick Matthäi pmatth...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael S Gilbert schrieb: On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote: Hi. Some time ago, I've wrote several bug reports to packages, that download files from some non-apt-secured sources of the web, and install them. i also started a similar discussion a while back, which was met with mixed opinion [0]. i tried to lay out the full spectrum of issues related to this problem, but many just focused on the non-free aspect. no consensus was reached. checksums are a good start, but if the data itself is non-free (or closed or obscured), then how can you be sure it is not malicious? i think it is a matter of trust, and maybe the key would be that scripts should only accept the external data if it is signed and hashed by an authenticated DD's gpg key. This would be a good option. But I think you do not have access to the upstream files and also you can not sign them, maybe upstream itself also do not want to do it. Hosting them on my own host is also not a good option. you could host just the hashes for the external files (signed with your key) on your site. then you wouldn't have to duplicate upstream's data files nor spend (much) of your own bandwidth (since the hash files should be fairly small in most cases). or maybe there could be a hash.debian.org or a project on alioth to centralize the hashes? mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote: Hi. Some time ago, I've wrote several bug reports to packages, that download files from some non-apt-secured sources of the web, and install them. i also started a similar discussion a while back, which was met with mixed opinion [0]. i tried to lay out the full spectrum of issues related to this problem, but many just focused on the non-free aspect. no consensus was reached. checksums are a good start, but if the data itself is non-free (or closed or obscured), then how can you be sure it is not malicious? i think it is a matter of trust, and maybe the key would be that scripts should only accept the external data if it is signed and hashed by an authenticated DD's gpg key. mike [0] http://lists.debian.org/debian-devel/2009/02/msg00461.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Talk: Reflections of a bigtime Debian bug reporter
On Tue, 15 Sep 2009 23:19:12 +0200 Julien Cristau wrote: On Tue, Sep 15, 2009 at 16:41:50 -0400, Michael Gilbert wrote: the answer to the real problem is education. if a user didn't submit sufficient details in their report, politely ask them for more. show them a guide for strace, or bug writing guides, or debian documentation, or whatever may be useful. this may be more work, but as that user gains more skill, they will become less of a burden, and more importantly, more capable of solving problems and writing good reports on their own. you really think that's how it works? how about if a user didn't submit sufficient details, then either their bug gets ignored for years, or maybe at some point we ask for more info and they're unresponsive, meaning the bug never gets fixed. of course many cases will not produce a self-actualizing contributor, but it is worth the effort for those that do. karma. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dash pulled on stable when APT::Default-Release is used
On Wed, 29 Jul 2009 13:00:13 +0200, Felix Zielcke wrote: Am Mittwoch, den 29.07.2009, 02:25 +0200 schrieb Vincent Danjean: Hi, Since a few days, on a stable machine (with stable, testing and unstable sources for apt but APT::Default-Release set to stable), apt-get dist-upgrade wants to install dash. Can someone explain me why ? Is it due to the fact that dash is essential in unstable ? I assume it is. I thought I read somewhere that the reason why bash started to depend on dash would be that apt doestn't pull in new essential packages. Though on IRC I was told it does that already for a long time. So if you don't want dash installed to be on a system which mainly uses stable you have to remove unstable from sources.list But I think dash doestn't hurt, it's small and I use it as /bin/sh since a year or so without problems. i think the real issue here is that getting dash pushed onto your stable system is a somewhat unwelcome surprise (not that it is necessarily harmful). it will certainly cause some concern for certain security-conscious users since it is not coming from a point release or DSA update, which may lead to paranoia of malicious activity. perhaps an announcement should be made to state that this action is expected and ok. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dash pulled on stable when APT::Default-Release is used
On Wed, 29 Jul 2009 19:20:02 +0200, Vincent Danjean wrote: Michael S. Gilbert wrote: Am Mittwoch, den 29.07.2009, 02:25 +0200 schrieb Vincent Danjean: Hi, Since a few days, on a stable machine (with stable, testing and unstable sources for apt but APT::Default-Release set to stable), apt-get dist-upgrade wants to install dash. Can someone explain me why ? Is it due to the fact that dash is essential in unstable ? i think the real issue here is that getting dash pushed onto your stable system is a somewhat unwelcome surprise (not that it is necessarily harmful). it will certainly cause some concern for certain security-conscious users since it is not coming from a point release or DSA update, which may lead to paranoia of malicious activity. You need to have unstable sources in apt for this to occur. A plain stable (lenny) system will not see that. It is not really a concern for me (the lenny dash that is pulled does not change /bin/sh by default and dash is not a big package). I was just wondering if this behavior was a feature or a bug. And it was also a surprise for me. it is a bug in the sense that stable's behavior is being unduly influenced by unstable's essential packages list. i would suggest submitting a report to the bts so the problem can be tracked and eliminated in future releases. mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Breaking /emul/ia32-linux for squeeze
On Wed, 11 Mar 2009 21:12:31 +0100, Kurt Roeckx wrote: On Wed, Mar 11, 2009 at 05:46:31PM +, Clint Adams wrote: It may be time to change packages installing files to /emul/ia32-linux (which violates the FHS) to use /usr/lib32 instead. /usr/lib32 isn't exactly FHS either, but it's better than /emul/ia32-linux Will this also change for ia64? As far as I know, there that path is hardcoded in the kernel. Is this necessary? There are already softlinks set up: /usr/lib32-/emul/ia32-linux/usr/lib and /lib32-/emul/ia32-linux/lib. If debian is going to go down this road, then I think plain old lib should also get removed in the process (e.g. put everything into either lib32 or lib64; temporarily provide a lib softlink until a full transition happens). This could make a 64 to 128 (or other bitness) transition and associated backwards-compatibility easier, perhaps... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Security Issue of .desktop files
On Tue, 24 Feb 2009 17:32:57 -0300, Daniel Ruoso wrote: By who? The Browser? Fix the browser? Please take a look at all the discussion in the bug reports, I don't think we need to repeat all the argumentation here. I think Yves is saying that the launcher issue is (and always was) correctly handled in the XFCE desktop. This is a GNOME/KDE-specific problem. If the browser (iceweasel, epiphany, etc) handles the launchers via its own means, then there still may be a problem, but that would certainly not be the fault of the desktop environment. If there are indeed vectors for attacks via browsers, then bugs should certainly be reported against their BTS's. But first, please determine whether the vector exists. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Security Issue of .desktop files
On Tue, 24 Feb 2009 19:09:42 -0300, Daniel Ruoso wrote: So if a .desktop file appears in the user's Desktop without the x bit set and the user clicks it, it won't get executed.. Not exactly. The “safe” .desktop file was in the link I pasted on another mail in the thread: So if the launcher use a plain name like Nude Shots, it will get executed? I think I need to retract my previous statement. It looks like the XFCE desktop itself is fairly safe (since it never actually executes .desktop files), but thunar isn't. For example, here is a .desktop file that looks like it is iceweasel, but really it downloads an essentially random file, but I could have made it do pretty much anything. filename: random.desktop [Desktop Entry] Version=1.0 Name=Iceweasel Exec=wget http://people.debian.org/~joeyh/d-i/images/daily/stats.txt Icon=/usr/share/pixmaps/iceweasel.png The user is not warned that this may be malicious, it has the iceweasel icon and name, and runs without prompt when clicked on in thunar. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Security Issue of .desktop files
On Tue, 24 Feb 2009 23:44:31 +0100, Yves-Alexis Perez wrote: here is a .desktop file that looks like it is iceweasel, but really it downloads an essentially random file, but I could have made it do pretty much anything. Yes, tests may need to be narrowed. That should be part of the spec, though. It seems like it will error-prone, troublesome, and a lot of work to come up with enough robust test cases that can prevent all potential attack vectors (especially if its on a deny per-application basis). Does it even make sense for anyone to be spending time on this? Ultimately there are going to be holes, and thats where attackers will get through; they have a lot more time to mess around and think about this stuff than most of us. Requiring '+x' has got to be the best, easiest, most straightforward, and most robust solution on the table. In order for a malicious launcher file to work, users will have to be smart enough to be able to use chmod, and if that's the case then they'll know something suspicious is going if someone tells them to do it. Chmod is required because, for example, thunar does not allow the user to modify the executable bit and I hope nautils/dolphin behave the same) It's going to take some effort to get this solution implemented, but its the right thing to do, and Debian should plan to proceed forward with that. Regards, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Post-Lenny discussion on packages with external (potentially non-free) dependencies
Dear All, First of all, congratulations on getting the Lenny release out the door! I understand that it was a lot of work, and you're probably looking forward to at least somewhat of a break. So I don't want to treat this problem with too much urgency (yet), but I would like to get a dialog going as people find the time to weigh in with their opinions. In the following, I recap the core problems at hand (listed in terms of importance/relevance) and the arguments on both sides that have been developed in the bug report [1]. Summary of the problem: Some packages such as foo2zjs, pciutils, ttf-mathematica4.1, etc. have components that download files external to the Debian archives (from the internet) at runtime, which is problematic in many ways. 1. Provides a potential avenue for introducing malicious software onto users' systems Argument: Since the standard checks and balances (digital signing of packages by developers) is circumvented by fetching files from an unreliable source, it is possible for an attacker to either hijack or spoof the upstream site to introduce malicious software onto users' systems. This may seem obscure, for example, for foo2zjs's printer firmwares, but the getweb script does provide an update mechanism, so the attacker could use that to introduce his malicious code. Regardless of how obscure an attack vector may be, I just don't think that it is worth the risk to allow it to remain open. Rebuttal: Since this script explicitely downloads stuff from an author's webpage (and it is stated like that), the user knows the risk. Are you proposing to call this a security issue? Then packages like iceweasel are also affected and many others ... Response: The user may not, and likely does not, fully appreciate the risk. I'm sure that most users trust that the Debian developer has considered and appropriately mitigated the risk for them, or more likely, they do not consider risk at all. They just use their computer. Iceweasel is not a very good analogy because it is generally not run as root and is not permitted to execute downloaded files without a smart (chmod'ing) user involved. 2. Components of the package may stop working in the midst of a stable release's lifetime Argument: Since the location and composition of external files is outside of the package maintainer's control, upstream changes can break stable scripts. Rebuttal: This is a simple bug. If it happens, we'll fix it, full stop. Response: This may be a permissable fix for a stable point release, but it leaves the system potentially broken for an indeterminant amount of time (e.g. foo2zjs's getweb in etch was broken for over a year) between those releases (depending on when the break happens). This also depends on users' willingness to report bugs in stable. This usually doesn't happen because people know that stable is stable and doesn't get changed. It may also be possible to address this problem via maintainence in volatile, but do they want to take on more responsibility? 3. Allows packages in main to depend on external files, violating the spirit of the Debian Policy Argument: Section 2.2.1 of the Debian Policy Manual states that ...packages in main must not require a package outside of main for compilation or execution..., and section 2.2.2 states that [e]xamples of packages which would be included in contrib are free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, ... This seems to make it very clear that external dependencies are unacceptable in terms of packages, but does not make clear the policy on general data and files. However, given an honest attempt at interpretation, it would seem that the same conclusion shoud apply equally to general files as well as packages. Rebuttal 1: This is a grey area of Debian Policy, and a litteral interpretation of the manual says that the current behavior is OK. Response 1: We shouldn't make judgements based solely on the wording as written, but instead based on the original intent of the author (as an aside, this is why the judicial branch's role in the government is so complicated and controvercial). Just because the writer chose to use the term package does not mean that they did not intend to cover all files in general. Rebuttal 2: Objection to single script packages (maintainers do not want to maintain separate packages in contrib that contain only these externally depending scripts). Response 2: Decisions should not be made based on potential inconveniences or work load. Besides, it is not that difficult to build and maintain additional binary packages. The offending scripts can remain within the original the source packages. 4. Parts of the package work as intended only under certain circumstances Argument: Since an internet connection is not guaranteed on the user's end, the program does not work as intended when the net is either down or unavailable. For
