http://permalink.gmane.org/gmane.comp.security.oss.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.security.oss.general/7767 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/25/2012 11:59 AM, Peter van Dijk wrote: Yeah we probably should have started a new thread at some point =). - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPv8siAAoJEBYNRVNeJnmTmBEP/3knGQ2O9jYENr9iEDNHF6WT WefK13a5Rs4y24HnPk9QfiAdZMp5UAsUGQzKT6quUlcLQqhj+OpRSkynhC8lfu9r 0DJ6YhCDW0LH4XLDk7/DedWK0kUPLLnfESxqnnvDQWT+sDRbdFNEFxZWN9TqWxlG JTyupBoxNr7Ozy7O53cYE9t82Aseg+BJr2Rd7/b6cuV0gLls96PE7o39Z6/IAVYc tcQmxOIZ+pbEmzFS0IzAUHN5KitvNndVnclGpbTwh2+ZsPRHGuiWXGSDBm9WXTi4 OVA4qbFHQ244SzFZybgxWfj8yC726JnDI48vwBcnr6OJr+KvZBgdtxPfeQMNSxSf GA5Y30KU1cxR0TvjhdIMvhFRKnH0ybYXCDkuHRYhFyyoISOaA9WgqN3CLd1f5U5L e+AMShz8HDqNpNTGb1JiG+SMswoa+z3/utIlq8kQGbsyjtZThcter6IJNqRxaEDN QoWhxSVYXg3OIj4aBNAgeY3yhGI02wfbEjNP874IXpU3h4LqktRcktfT5+c5JzBy 1d8gF2kx2rifwsj7CF0eR</pre> Kurt Seifried 2012-05-25T18:10:42 http://permalink.gmane.org/gmane.comp.security.oss.general/7766 <pre>Hello list, On May 25, 2012, at 19:55 , Kurt Seifried wrote: Just in case this slipped by someone - the example given (that adds root) is not for PowerDNS but for arpwatch! Kind regards, </pre> Peter van Dijk 2012-05-25T17:59:48 http://permalink.gmane.org/gmane.comp.security.oss.general/7765 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/24/2012 04:56 PM, Solar Designer wrote: Ok this part I did not know, so this is an obvious trust boundary violation (the intention was to drop privileges but it instead ADDS root privileges). Please use CVE-2012-2653 for this issue. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPv8emAAoJEBYNRVNeJnmTOS0P/Auu3FH4/CL9HEk9cDlZI7yV CdwfjVCE9TbNq+0eGLMNqdcYHB480oKRiv2Hz+qRbZKEzsUkiFPz4AdC/OvYfb2J ZuI8qqj3vNHCARr8O522rom0InfmIDhFgbq/b5Hde08B80C7s6p15j6tOet8YT8r b7deG21Z5GZ0AmEPxKB0Y2nXrOG6ahkVXg2sRTVE6vE22yleS7k6tSw6cTBichoa F1weUygQxEKRtKIawr6e9Kr39xQepBBxhnUQMSnQiZgDYT/fW4QTCDD/Z+IiY51Q H+dUMKV/oqFIcXy4ht0sdq12dABuZ6+06BwC7oS/pMeDebAOIAybDqvNcnrEk1fw rJt/ZS+Rxbk7b6jdNeTskOlRtKOZkGz+Bs1uMcZhPXVmcNpv1pbq70AJHIwD1E2X LPYQS30xiGqfIdcGGZ9qbfwrP</pre> Kurt Seifried 2012-05-25T17:55:50 http://permalink.gmane.org/gmane.comp.security.oss.general/7764 <pre>Morning, I only asked for a CVE for this issue in powerdns because I have seen other projects asking for CVE id's regarding this exact issue. If it shouldn't get one then it shouldn't get one :-) -- Thank you. </pre> David Black 2012-05-25T13:04:51 http://permalink.gmane.org/gmane.comp.security.oss.general/7763 <pre>Hi, Steve. Just a friendly heads-up on what came through CVENEW today: This should be rejected as per the message two responses after the first reference above: http://www.openwall.com/lists/oss-security/2011/08/10/2 where Eugene says, based on the "this isn't a security flaw" message from Dan Rosenberg. Can you add a "REJECT" or "DISPUTED" note or whatever? This probably should have never been written up. Thanks. </pre> Vincent Danen 2012-05-25T04:11:09 http://permalink.gmane.org/gmane.comp.security.oss.general/7762 <pre></pre> Christos Zoulas 2012-05-24T23:50:38 http://permalink.gmane.org/gmane.comp.security.oss.general/7761 <pre>CVE-2012-2417 https://bugs.launchpad.net/pycrypto/+bug/985164 PyCrypto (also known as python-crypto) versions 2.5 and earlier implement incorrect ElGamal key generation. The bug has been fixed in PyCrypto 2.6, which was released this morning. Details below: In the ElGamal schemes (for both encryption and signatures), g is supposed to be the generator of the entire Z^*_p group. However, in PyCrypto 2.5 and earlier, g is more simply the generator of a random sub-group of Z^*_p. The result is that the signature space (when the key is used for signing) or the public key space (when the key is used for encryption) may be greatly reduced from its expected size of log(p) bits, possibly down to 1 bit (the worst case if the order of g is 2). While it has not been confirmed, it has also been suggested that an attacker might be able to use this fact to determine the private key. Anyone using ElGamal keys should generate new keys as soon as practical. Any addit</pre> Dwayne C. Litzenberger 2012-05-24T23:30:54 http://permalink.gmane.org/gmane.comp.security.oss.general/7760 <pre> Yes. If you put that one snippet of code into google, you would find arpwatch is the culprit. It was more of an empirical thing. I had a script that started all daemons and it walked the proc tree. If any uid != 0, it would check to see if there were any supplemental groups. Arpwatch had different supplemental groups than everything else that did this wrong, so I looked at the code to see what was different and found this bug. -Steve </pre> Steve Grubb 2012-05-24T23:18:14 http://permalink.gmane.org/gmane.comp.security.oss.general/7759 <pre> Wow. The NULL results in group 0 being added to the supplementary groups list (so it survives the setgid(), at least on my quick test). How did you spot this? Compiler warning? "passing arg 2 of `initgroups' makes integer from pointer without a cast" Alexander </pre> Solar Designer 2012-05-24T22:56:46 http://permalink.gmane.org/gmane.comp.security.oss.general/7758 <pre> I have to agree. Changing UID/GID from root to something else is a security feature by reducing privileges and write access to system files. Not doing it correctly is CWE-271. Looking it up, you can easily find 2 CVE's that are about not dropping supplemental groups. If it were intended that you change uid/gid but retain a supplemental group, then you don't understand how /etc/group was supposed to be setup and used. Additionally you would have called initgroups() to pickup the new group memberships associated with that acct. So, its always wrong to call setgid()|| setuid() without taking care of supplemental groups. Failing to drop supplemental groups, though, is not a vulnerability. Its an exposure to risk because you can bet someone will find another hole and exploit it and these extra privs allow them to escalate further. Here is a real life case: + if ( initgroups(pw-&gt;pw_name, NULL) != 0 || setgid(pw-&gt;pw_gid) != 0 || + setuid(pw-&gt;pw_uid) != 0 ) This is no</pre> Steve Grubb 2012-05-24T22:15:53 http://permalink.gmane.org/gmane.comp.security.oss.general/7757 <pre>Kurt - On Thu, May 24, 2012 at 02:33:06PM -0600, Kurt Seifried wrote: It's a case of a security feature not working as intended. Previously, CVEs were sometimes assigned and sometimes not in such cases, and I failed to see a pattern in that. ;-) Consider e.g. CVE-2006-5794 ("it is believed that this issue is only exploitable by leveraging vulnerabilities in the unprivileged process, which are not known to exist"). Are you maybe trying to draw the line between "security feature" and "security hardening"? Even if so, I fail to see how OpenSSH's privsep is more of a "security feature", whereas another daemon's dropping of root privs is "security hardening". These look very similar to me in terms of what they're intended and expected to achieve, so I think it's the same category, whatever we call it. Now, I imagine there could be a subtle case if e.g. a downstream distro or a fork of a project introduces privilege dropping, which is not in the main code base, and there turns out to be a flaw in that, whi</pre> Solar Designer 2012-05-24T20:57:30 http://permalink.gmane.org/gmane.comp.security.oss.general/7756 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/24/2012 02:10 PM, Solar Designer wrote: Ahh I realize something I forgot to cover in my email is the distinction between vulnerability and vector, e.g. if program "foo" (for the sake of argument let's say it is a text editor) doesn't drop supplementary groups correctly than exploitation of it would be easy, so in this case I'd agree it was a security vuln. But when a program with much more limited operations doesn't drop privileges, unless it directly leads to some sort of exploit/elevated access/etc. than I'm inclined to say while it's not good, it's not a vulnerability per se. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPvpsCAAoJEBYNRVNeJnmTHIIQAIA3A/fehKMDeXegQ8t7ObbK PT+eTwn5TbRwxkdmvloF3wVFUoAv6C58obq349AmOKc/BXaM4Nf3tgnxiUKLm57</pre> Kurt Seifried 2012-05-24T20:33:06 http://permalink.gmane.org/gmane.comp.security.oss.general/7755 <pre>Kurt - On Thu, May 24, 2012 at 12:40:10PM -0600, Kurt Seifried wrote: That's what initgroups(3) is for. If a program that is supposed to drop privs calls neither setgroups() nor initgroups(), or if it fails to check the return value from these and refuse to proceed on failure, then it is vulnerable. Definitely. It should be. Having supplementary groups of the new (pseudo-)user, possibly yes. Having supplementary groups of the old switched-from user, no. Alexander </pre> Solar Designer 2012-05-24T20:10:04 http://permalink.gmane.org/gmane.comp.security.oss.general/7754 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/24/2012 01:10 PM, Miloslav Trmac wrote: Ok I'll admit it, bad example, but I couldn't think of anything better offhand. Any ways like I said if someone can make a compelling argument that these should all be security issues that's great, if not I'll continue to default this to a security hardening issue unless someone brings up specific instances that need to be dealt with as a security fix. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPvpLRAAoJEBYNRVNeJnmTckQQAJM5wgUAeYJlXXiCgkjW+u9/ T/SLE2S/cszH2iCTDYbzoUZOVbd/a92tlM/SEA+OwGt1/0UR4OtTtH99EjU93TzH ejWOJAzcyM1XRsuttcAbwKnCY7tNRxrBkzxMp8bE2Mdpt+NB3BJhyczpliU1SaRp 5gNAIZK+LnxsTsP7YAlI5dMfFLKcr5UnZEGzJ4M6boNvC6+N6LAIukjLpTGR1kLr Uwq3YHQj0R4OzyYpaqmuaYbIbF+E9OAp/yrToZ7wyaeEHaXuj4ePd6pm50M</pre> Kurt Seifried 2012-05-24T19:58:09 http://permalink.gmane.org/gmane.comp.security.oss.general/7753 <pre>----- Original Message ----- Yes, the existence of supplementary groups is intentional - but that doesn't mean that inheriting supplementary groups is intentional. From the administrator's point of view, the privileges are effectively assigned to "the user" as an "atomic" identity - they are configured in /etc/passwd and /etc/group _and associated with an UID_. In "ordinary" case, programs running with a specific UID are expected to always use the same primary GID, and same primary groups. Yes, the implementation does not match the administrator's point of view, the UID, GID and supplementary groups are sparete, and , e.g. setuid/setgid may cause a different configuration from the "primary" case, or switching privileges temporarily creates non-ordinary situations. Still, I think that keeping the administrator's point of view in mind is important. In the above example, if there really is a "logging" group, and an application is configured to drop privileges and switch to uid $APP_UID, the administrator </pre> Miloslav Trmac 2012-05-24T19:10:25 http://permalink.gmane.org/gmane.comp.security.oss.general/7752 <pre> Supplemental groups are just for file access or anything that does a group permission check. The only way to determine if this is a security problem is to run the find command looking for any file with that group. Maybe something like this (assuming root): find / -path /proc -prune -o -type f -gid 0 -perm /00030 -printf "%-55p %g\t%M\n" What programs that don't drop privs correctly does is call attention to it as something that should be attacked because it can be used as a stepping stone to other parts of the system. On the programming side, these should always be fixed so that we err on the side of caution. On the CVE issuing side you probably want to see what files exist with permissions that could be used to help decide its importance. For example, there are a number of files that are group root writable and even more that are group root readable. So, dropping root badly can eventually lead to system compromise in a few steps. but when other groups are involved, you need to run the find c</pre> Steve Grubb 2012-05-24T19:16:33 http://permalink.gmane.org/gmane.comp.security.oss.general/7751 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CC'ing the PowerDNS guys. On 05/24/2012 10:20 AM, David Black wrote: So the dropping of groups and the dropping of supplementary groups has come up a lot recently, here are my personal thoughts on the matter (with thanks to Steve Grubb for explaining some of the trickier bits). These are of course my personal opinions, any mistakes/errors are mine entirely and so on. Dropping of the primary user and group privileges is a well known security feature in many programs (e.g. bind, dhcp, apache, etc.). The idea being programs need root to bind to privileged ports/etc. But once done don't need root access. I think clearly in this case if a program is running as root, and claims to give up root privileges but fails to, that is a security issue and worthy of a CVE. In the case where a program does NOT drop privileges, and this feature has now been added (and assuming it works), I think this qualifies as security hardening, not a security fix and NOT worthy of a CVE.</pre> Kurt Seifried 2012-05-24T18:40:10 http://permalink.gmane.org/gmane.comp.security.oss.general/7750 <pre> no, that is CVE-2012-1179. petr </pre> Petr Matousek 2012-05-24T18:08:05 http://permalink.gmane.org/gmane.comp.security.oss.general/7749 <pre>is 1a5a9906d4e8d1976b701f889d8f35d54b928f25 the upstream fix? -armin On 05/18/2012 02:37 AM, Petr Matousek wrote: </pre> akuster 2012-05-24T18:03:00 http://permalink.gmane.org/gmane.comp.security.oss.general/7748 <pre>Powerdns does not drop/clear supplementary groups in its dropPrivs routine where the intent is to drop privileges. The relevant code can be found in pdns/unix_utility.cc / pdns-recursor-3.3/unix_utility.cc [0]. Can a CVE id be assigned for this issue? [0] pdns/unix_utility.cc / pdns-recursor-3.3/unix_utility.cc // Drops the program's privileges. void Utility::dropPrivs( int uid, int gid ) { if(gid) { if(setgid(gid)&lt;0) { theL()&lt;&lt;Logger::Critical&lt;&lt;"Unable to set effective group id to "&lt;&lt;gid&lt;&lt;": "&lt;&lt;stringerror()&lt;&lt;endl; exit(1); } else theL()&lt;&lt;Logger::Info&lt;&lt;"Set effective group id to "&lt;&lt;gid&lt;&lt;endl; } if(uid) { if(setuid(uid)&lt;0) { theL()&lt;&lt;Logger::Critical&lt;&lt;"Unable to set effective user id to "&lt;&lt;uid&lt;&lt;": "&lt;&lt;stringerror()&lt;&lt;endl; exit(1); } else theL()&lt;&lt;Logger::Info&lt;&lt;"Set effective user id to "&lt;&lt;uid&lt;&lt;endl; } } </pre> David Black 2012-05-24T16:20:59 http://permalink.gmane.org/gmane.comp.security.oss.general/7747 <pre>Social Engine 4.2.2 Multiples Vulnerabilities Earlier versions are also possibly vulnerable. INFORMATION Product: Social Engine 4.2.2 Remote-Exploit: yes Vendor-URL: http://www.socialengine.net/ Discovered by: Tiago Natel de Moura aka "i4k" Discovered at: 10/04/2012 CVE Notified: 10/04/2012 CVE Number: CVE-2012-2216 OVERVIEW Social Engine versions 4.2.2 is vulnerable to XSS and CSRF. INTRODUCTION SocialEngine is a PHP-based white-label social networking service platform, that provides features similar to a social network on a user's website. Main features include administration of small-to-mid scale social networks, some customization abilities, unencrypted code, multilingual capability, and modular plugin/widget compatibility. There is a range of templates and add-ons available to extend the basic features already included in the SocialEngine core. VULNERABILITY DESCRIPTION == Persistent XSS in music upload. == CWE-79: http://cwe.mitre.org/data/definitions/79.html The software does not neutralize o</pre> Tiago Natel de Moura 2012-05-24T06:09:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.oss.general