Bug#712744: gnupg-agent: Doesn't call prctl(PR_SET_DUMPABLE, 0, 0, 0, 0)
Hello Samuel, looks like valid request. Upstream bugzilla entry created at: [1] https://bugs.g10code.com/gnupg/issue1509 Thank you Regards, Jan. -- Jan iankko Lieskovsky -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702710: smarty: Possible XSS bug in Smarty error messages.
Hello, https://code.google.com/p/smarty-php/source/detail?r=4660 Good catch, thanks for your report :) And I've made a debdiff as attached. security team I think it would be released as stable-proposed-updates since it has no CVEs, so I guess we probably say no DSAs for it. Just FYI the CVE identifier of CVE-2012-4437 has been previously assigned to this issue: http://www.openwall.com/lists/oss-security/2012/09/20/3 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4437 And I don't know QA upload can be done as such way, so please let me know appropriate manner for upload if you know it. Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693087: segfault in xscreensaver, screen revealed
Thank you for your report, Ian. Package: libpam-rsa Version: 0.8-9-2.4 Tags: security * What led up to the situation? 1. I manually locked my screen using xscreensaver-command -lock. 2. I moved the pointer, causing the xscreensaver password screen to appear. 3. I moved the pointer some more and waited for the timeout to expire. * What was the outcome of this action? xscreensaver crashed with a segfault, and the screen was unlocked, including a root shell window. This is very repeatable. It may be relevant that I use libpam-rsa instead of the normal pam-unix for login. Is it possible to reproduce that xscreensaver crash also without libpam-rsa module being used? (when using pam-unix login alternative with the same scenario) Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png Rule 420: All persons more than eight miles high to leave the court -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689991: CUPS: error_log flooded due to AllowUser restriction
Thank you for your report, Sergio. Package: cups Version: 1.5.3-1 Severity: important Tags: security I've created a print queue with an AllowUser user1 option. When submitting a print job as user1 all goes as expected, but if I submit it as some other user I see a flood of error messages appear (observed rates: 375-500 Hz, depending on the client) in /var/log/cups/error_log: E [08/Oct/2012:20:31:23 +0200] Returning IPP client-error-not-authorized for Create-Job (ipp://xxx.yyy.zzz.ttt:631/printers/test1) from aaa.bbb.ccc.ddd cupsd consumes significant amounts of CPU time while the client is trying to submit the job. Could you be more specific what 'significant amounts of CPU time' means (30% / 50% / 90%)? Also, which cupsd would spin trying to log this error, are print jobs / requests from valid users still served properly? Both the log flood and the CPU consumption stop as soon as I cancel the print job on the client. Thank you Regards, Jan. -- Jan iankko Lieskovsky -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677418: Due Debian bug #677418 -- gpm sharing clipboard between different users
Hi Chris, thank you for your reply. On 06/15/2012 02:03 AM, Christoph Anton Mitterer wrote: Hi. First gpm has no bug tracker right? So could you please CC the Debian bug, that we can record all this at some central palce? :) As noted, didn't file Red Hat Bugzilla bug yet, since I am not completely sure this is a security issue (and first wanted to obtain feedback from gpm developers / upstream). On Thu, 2012-06-14 at 11:06 +0200, Jan Lieskovsky wrote: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677418 I've updated some information there: Mainly that I think that ideally, a clipboard should be kept per logged in user (and obviously each user should only get access to his clipboard). This includes, that a user's clipboard is removed one he has logged out from all his sessions. It does not mean, that there should be a clipboard for each terminal of a user. I don't see that far into gpm code. Maybe the callback handling paste-clipboard event should check for UID (if it's the same as was used in the copy-clipboard callback handler). Have tested the reported behaviour in two different subcases: 1) try just two tabs, under each one of them logged in as different user (under first one as 'root', under another as common, unprivileged user). In this case the described behaviour works (IOW area selected by root is paste-able by unprivileged user). Note that this is of course not only a security hole between root/user-A but also between user-A/user-B situations. Sure, just focused on root/unprivileged user scenario in my testing. But I would not consider this to be a trust boundary cross (security issue). If you can login as root to some system, the fact that when you log in to the same host as unprivileged user within the same application isn't such a big deal. I can't understand why you think this... especially on multi-user systems it IS absolutely critical. The system could be some terminal computer where people from many different places can access a console. Right, valid concern. 2) but tried also KDE's konsole vs Gnome's gnome-terminal (being logged in as root in KDE's konsole, later login as unprivileged user to the same host via gnome-terminal and try to paste the content). It still allowed the unprivileged user to see the content of selected root area (content of clipboard). I don't exactly understand what you did there... gpm shouldn't work within X at all, should it? Didn't know about this restriction. But noticed now in gpm's manual page. You think it should be considered a security issue or not? (IMHO gpm should use separated clipboard for each of the users, so it would not be possible one user to see the clipboards content of the other) See my comments above, that go even a bit further... Obviously session tracking would complicate things a bit,... one could e.g. use consolekit for this, but that may be an unwanted dependency. Didn't completely mean separated clipboard for each of the users (like there would be another instance for each of them). Was rather thinking of checking UID when pasting, if it matches UID used for copying (but not sure this would be implementable). Will let gpm developers to reply here. From a theoretical security point of view, there should be no strict need, to clear a user's clipboard when all his sessions are logged out. Because an attacker that gains access to this (and could therefore read the clipboard on subsequent re-logins) could probably also install key-loggers or so. But it may be helpful on systems where multiple persons share one account (in theory each person should have it's own account, which is why I wrote theoretical above)... an it's also the behaviour of X' clipboard. Thanks Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team P.S.: Nico, Nikola could you let us know your opinion on the above? (upstream view at the issue as a whole and possibilities how to fix it [if willingness]). Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649322:
The CVE identifier of CVE-2011-4357 has been assigned to this issue: [2] http://www.openwall.com/lists/oss-security/2011/11/28/6 Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649322:
The CVE identifier for this issue has been requested here: [1] http://www.openwall.com/lists/oss-security/2011/11/27/1 Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631818: CVE Request -- DokuWiki -- XSS in DokuWiki's RSS embedding mechanism
Hello Josh, Steve, vendors, it was found that DokuWiki's RSS embedding mechanism did not properly escape user-provided links. An attacker could use this flaw to conduct cross-site scripting (XSS) attacks, potentially leading to arbitrary JavaScript code execution. References: --- [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631818 [2] http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-366/CERTA-2011-AVI-366.html [3] http://www.freelists.org/post/dokuwiki/Hotfix-Release-20110525a-Rincewind [4] https://bugzilla.redhat.com/show_bug.cgi?id=717146 Solution: - This issue has been addressed in upstream 2011-05-25 Rincewind release: [5] http://www.dokuwiki.org/changes This issue doesn't seem to have a CVE identifier yet. Could you allocate one? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629938: CVE Request -- dbus -- Local DoS via messages with non-native byte order
Hello, Josh, Steve, vendors, It was found that D-BUS message bus service / messaging facility did not update the byte-order flag of the message properly by swapping the byte order of incoming messages into their native endiannes. A local, authenticated user could use this flaw to send a specially-crafted message to a system service (like Avahi or NetworkManager), using the system bus, potentially leading to disconnect of such a service from system bus (denial of service). References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629938 [2] https://bugs.freedesktop.org/show_bug.cgi?id=38120 [3] https://bugzilla.redhat.com/show_bug.cgi?id=712676 Upstream patches: [4] http://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.2id=6519a1f77c61d753d4c97efd6e15630eb275336e (in upstream v1.2.28 version) [5] http://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.4id=c3223ba6c401ba81df1305851312a47c485e6cd7 (in upstream v1.4.12 version) Could you allocate a CVE id for this? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629511: CVE Request -- Data-FormValidator -- Reports invalid field as valid when untaint_all_constraints used
Hello, Josh, Steve, vendors, It was found that perl-Data-FormValidator, a HTML form user input validator, used to treat certain invalid fields as valid, when the untaint_all_constraints directive was used (default for majority of Data-FormValidator routines). A remote attacker could use this flaw to bypass perl Taint mode protection mechanism via specially-crafted input provided to the HTML form. Note: Hopefully Damyan, Mark can clarify here, if valid data from Data-FormValidator are automatically marked as untainted for perl Taint mode or not. If there still is perl Taint mode protection check present, even on valid Data-FormValidator data and it couldn't happen, that tainted data would be passed further to the script processing, then this is not a security issue. References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629511 [2] https://rt.cpan.org/Public/Bug/Display.html?id=61792 [3] https://bugzilla.redhat.com/show_bug.cgi?id=712694 Could you allocate a CVE id for this? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583435: CVE Request -- rpcbind -- Insecure (predictable) temporary file use
Hi Steve, vendors, Guillem Jover pointed out: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#5 a deficiency in the way rpcbind gathered / saved registrations from / to dumped file(s). A local attacker could use this flaw to conduct symbolic link attacks, leading to un-authorized disclosure of sensitive information and / or to important system files data integrity corruption. References: [2] https://bugzilla.redhat.com/show_bug.cgi?id=599697 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#15 Could you allocate CVE id for this? Thanks Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570737: sudoedit permission in sudoers grants permission to any sudoedit, executables
Hi guys, CVE identifier of CVE-2010-0426 has been already assigned to this issue. Thanks Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
