http://blog.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/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 additional information about this bug will be tracked at the above URL. </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 not upstream. This is a patch to drop capabilities by changing uid/gid. The person writing the patch intended to do the right thing - but failed. See the bug? This is in a network facing daemon that parses untrusted network packets. -Steve </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, which weakens the added security (but not to the point of being worse than the original). It would feel a bit weird to say that the hardened revision is vulnerable whereas the original is not, even though the original is not any safer. In such cases, I guess whether this is CVE-worthy or not will depend on whether the added hardening was advertised to and expected by users/admins of the hardened revision or not. If it was an undocumented extra, then it failing to improve things is probably not what people would expect to be tracked as a security vulnerability. However, if it was documented and expected to function, then it becomes a vulnerability to track just like any other one of similar severity. I hope this helps. Alexander </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/BXaM4Nf3tgnxiUKLm570 yPjDdBGECBtMrLftQ5LMSwZCkygZicD1JRbS9moJJOoR9xK005FAZM1P3LJOo7Bv S4gNTD2Vz3p0v09o7axTsNfAcA/May5hOJ5jmSq+Oj098ShPGVmtAmQkfADRa+mP xjtC7qFojDbwR3OANRUqU0FTHym4PmroVyWBAgrZNnaIywNz0JTyVXIII03Iv6H+ fAHxXshQ9NSTlizoKmm2ylmAI7u4/s/EWBE9P89Qo/m5ei0CKpc5i1YfzK7bD0zL Q4Y4WEFSNxpath2nQ/SUJe3E9P/yI6SsL2jjxFvf+qnfNtVSMAXFOLS6rmoE4ioj wo4Hu7HBfkVnW9AJL/dAtSh6Xjv7AnxXHLb3yQ/9oOaaXRm0wNdJVTyw3BsvOHuf d7Q/4GQhCKVDnXgCUpBQHa9ccqqfnVT9aReWueSf1N1NMVxJJOIcst+KtaEhm6Wt i/tCMXc3alIeeMn8CzK66XaS/hToSwB73NTsaze4wSyJMUIqM1nlO64mOv5KNwZM DYvj35I2ICK31prIAFVlGxaNRNExW+ofv4l4RvyTXREpU4ew0sgRMjzoJWw0+0sk is3phnptl1+es4JrjRye =dDuN -----END PGP SIGNATURE----- </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/2nP3 /c0lSidCAh7n/5PISFDNg2wn8YN5juhVbUSwgKUM1Bmli2Db5CjyEDHP2Io8WVO2 sLzMHFVSDKdJ5gU7yoeAKxCXTqB7Jc1aUQ7h1IeDtdgIb3eqi+1+m+i7IVbBI0XS g3ZFAj1DO5idOseaveHSQhIfQpcZq/Ak30LXJULoJqsUkf/KxXNug9uu/8bpW/PY vluiLaGm+HOhT6YBOOA8Mz8kBlVf4jPw1wovytsChxZ40OXktflII9NaBI9n/8Bd oJTXg36pbqOrNWlxUSeQRD5rtPfz2nLU7GDqZUvT75evf2FdewboXGxb2Fdx49SR h/znEa3O5w87YYh2WjxvLqcl45wCmFa9wgj+ZaFPHFtLjXCTllmLIg30RAeUNvxg uAmGCpqTV+sYbsTRtVnf =0vyF -----END PGP SIGNATURE----- </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 would expect that whether the app should or should not have the "logging" group membership is configured in /etc/groups for $APP_UID, not for root. So, I can't see that as an argument for intentionally not dropping supplementary groups. Mirek </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 command. For anyone wanting to go bug hunting, I have a script here: http://people.redhat.com/sgrubb/security/find-nodrop-groups that can be used. It finds many, many problems dropping supplemental groups. More than I alone want to fix. -Steve </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. Now it gets messy. What about the dropping of supplementary groups? Supplemental groups enabled a user to be a member of more than one group at a time (us old timers remember the joys of "newgrp"). Why would anyone want this? You could for example create a group that has permissions to access logging, terminals (e.g. modems, remember those? =) and then add users to it as appropriate (and centralize account/permissions management somewhat and all that good stuff). So what happens when a program starts running as say root, and root has supplemental groups (like "bin" or "daemon" and the program drops its primary user/group but fails to drop supplementary groups, is that a security issue, and is it worthy of a CVE identifier? For most cases I'm going to say probably not (aka no). Having supplementary groups is intentional and allows permissions to be more fine grained, you can for example make root a member of "logging" so that even when the app drops root privileges would still have the supplementary group of "logging" and can do its logging or whatever. So unless someone makes a compelling argument that these are security issues I'm going to err on the side of "security hardening" instead of "security fix" for dropping supplementary groups, but of course not all issues are the same so if you have a specific issue and think it deserves a CVE make a case on OSS-sec. * Should these issues be fixed? yes. Dropping privileges where possible is usually a good idea, until things break though and then people start disabling things like SELinux or running everything as root to "make it work" :P. - -- 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/ iQIcBAEBAgAGBQJPvoCKAAoJEBYNRVNeJnmT0NoP/0klqbji/ArTnVauB9U895Ye F8ck9XjRjdxTkmqSZB2rQiD2fmENkHFdZrmG8Vh8BLlnTreamOGwOiPIvX2dkGrM zDLoWbFVWD2ORGL7zUBL8KgJ3TkHsiXwGO0N7ojW7pun2S9HsWWtjIK2p0S/cjV+ rJAUg0vXeQ3d/ySzYNSuUIiyPFFYRMjNV4m35lTFwVz33d+hq9t6cf0JKzJLyH4h uqvhdOsYYrh4UOTkxSzdnWovtxsK16yvGrMFpa3N+4FGgqvlhDhwSvFj2aVWKy0I zQS1PpvJJiWfYzPRweze82yHLS22owmXBYl4Tl6igJB7l3v/uIzQJeExF+CWPTMB ZUdODKiDNd+jFqOUJcvrX0HJn1f/KJmNf11EdW3VZBrOpgKSLQUDJ43+RSGSDF6E tHfub3L1pZ4SbDXFVPzvlCzIsUkWhB8h3WwkTTZV2HbLdFiDDaInEH8wfwymc+2N YFvj+rjDj5dwftoTwutE92ElcCX8cpI51MqnvyaPChQCe1XdoF+wbM/+byyZHXZf tm/d19d/6Tjm7JmLIDfMWKFbGq8dJkuKjK4n2qZgqImd+2E1e2iLGB68pQvRDcgl BxGNlj1PL4THwkjMwjtO9s32JMlFcDYM3MjCt7GOSCOU9HyD7nNER10cH3oJ5n3S 1jkfJxJyNMowHJx3/nJH =6ZUw -----END PGP SIGNATURE----- </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 or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. Proof Of Concept: POST http://localhost/index.php/music/create POST data without form-data enctype: title=&lt;script&gt;alert(document.cookie);&lt;/script&gt;&amp;description=teste &amp;search=1&amp;auth_view=everyone&amp;MAX_FILE_SIZE=8388608&amp;filename= &amp;fancyuploadfileids=15 == Persistent XSS in creating events == POST http://localhost/socialengine/socialengine422_trial/index.php/events/create POST data without form-data enctype: title=teste XSS 3&amp;description=teste XSS 3&amp;starttime[date]=4/9/2012&amp; starttime[hour]=1&amp;starttime[minute]=0&amp;starttime[ampm]=AM&amp;endtime[date]=4/12/2012 &amp;endtime[hour]=1&amp;endtime[minute]=0&amp;endtime[ampm]=AM&amp;host=teste &amp;location=&lt;script&gt;alert(document.cookie);&lt;/script&gt;&amp;MAX_FILE_SIZE=8388608&amp; photo=&amp;category_id=0&amp;search=&amp;search=1&amp;approval=&amp;auth_invite=&amp;auth_invite=1&amp; auth_view=everyone&amp;auth_comment=everyone&amp;auth_photo=everyone&amp;submit= == Reflected XSS in search form of events area. == Direct javascript injected: POST http://localhost/index.php/widget/index/content_id/644 format=html&amp;subject=event_1&amp;search=';alert(document.cookie);var a = ' Proof of Concept: - - Go to URL: /index.php/event/$EVENT_ID - - Click on the "Guests" - - Click in "Search guests" form - - Submit: ';alert(document.cookie); var a = ' You will see your PHPSESSID in the alert. == Multiples CSRF vulnerabilities == CWE-352: http://cwe.mitre.org/data/definitions/352.html The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request. A CSRF in the plugin "Forum" allows forcing the owner of the event to do some activities such as: Close a topic: GET /index.php/forums/topic/4/example-topic/close/close/1 Open a topic: GET /index.php/forums/topic/4/example-topic/close/close/0 A CSRF in the plugin "Event" allows forcing the owner of the event to do some activities such as: Close the event: GET /index.php/events/topic/close/close/1/event_id/2/topic_id/2 Open the event: GET /index.php/events/topic/close/close/0/event_id/2/topic_id/2 "Watch Topic": GET /index.php/events/topic/watch/watch/1/event_id/2/topic_id/2 "Stop Watching Topic": GET /index.php/events/topic/watch/watch/0/event_id/2/topic_id/2 A CSRF in the plugin "Classifieds" allows forcing the owner of the event to do some activities such as: Open the classified listing: GET /index.php/classifieds/close/1/closed/0 Close the classified listing: GET /index.php/classifieds/close/1/closed/1 VERSIONS AFFECTED Tested with version 4.2.2 but earlier versions are possibly vulnerable. SOLUTION Upgrade to Social Engine 4.2.4. NOTES The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2012-2216 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. CREDITS Tiago Natel de Moura aka "i4k" SEC+ Information Security Company - http://www.secplus.com.br/ BugSec Security Team - http://bugsec.googlecode.com/ </pre> Tiago Natel de Moura 2012-05-24T06:09:42 http://permalink.gmane.org/gmane.comp.security.oss.general/7746 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2012 02:39 AM, David Black wrote: Please use CVE-2012-2395 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/ iQIcBAEBAgAGBQJPvStzAAoJEBYNRVNeJnmTGVwP/0dZWeEOJJg6fLfr66ToY6C4 33MB059f5k/ePfd/0hJwpNtSImvfACH+SvwLcGfCsVbj0HRPKg9EdkZlBRXplS50 EK9rL70casIG0p2DDxtd9L4AU8Kl6dsYGaoN3fL9nq3VdYtKJH0bHz1ryWaCG7ZN k0tDHRnPPfpcNxQNkvLiutRK2r0iR9ctzUioMErSFaee+mIVDCv3MNoGCnf4y/xH ijGB6GtuVAOLJzujSGyOLi6KdUgGJk2x9h6QUTN/iT9NE9/ukCrsdJP37MQUX3Sm Ft0fVlLcPt50FBq/ypEfrN7fl2P+isGpqpKBbI01qBQl9CiNOj3GoGOV2xsmlGU7 u832wbCLW/T1jRCacxfsjUCHiiEJBKOdd14HEuHStKpZY2FAwwVkSC35GcTfu+gA KtggmRYuQUKUZFu2unyWxtV6Thk97eT9UqWxrXj8UYoCl8YfaQXi0U+Ap2QB8Khr xVxzPsCl9tCuOlZMNss1YAXvwwjHu9o6AHX3tgPqjFFIveWxsOxRZSJ/ZveNgqjf 9JZuQvkODn4AD9NXwUgjjcokD7yfxOog43UWuoKOkNj71Eaxk+jU4Xk/mee3T7Wn zbXtOA/T9EO5Zu4yZB4El8bKm+9FJRlPk1LuQWTXlqW65vaZAkvd2PS2ifW2C74+ IyFclW5b9DOlyAMnTH7H =TMiW -----END PGP SIGNATURE----- </pre> Kurt Seifried 2012-05-23T18:24:51 http://permalink.gmane.org/gmane.comp.security.oss.general/7745 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2012 06:38 AM, Jan Lieskovsky wrote: Please use CVE-2012-2392 for these issues. Please use CVE-2012-2393 for these issues. Please use CVE-2012-2394 for these issues. - -- 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/ iQIcBAEBAgAGBQJPvSnCAAoJEBYNRVNeJnmT3WAP/ROKsmmsrbgxlmkXmcIu5ybM mdh19/1trkaU3l/jqeBlY1hIF1R4N6qvfNRwa2SdoPWaa3StubXlMHQ4XThMNQze 0yAQ2E/GD4LvnYjUBp9VLZbSYHDc61IJ5umwpU/cf9LPYSV+nBl5yVGLY/ynnidP EGDFJqYodmpfPCvTBdD3eZI2/gSqyy+kVznYUnduZZw30k7tvL0cVc9Vw3BA6DDG QtoSxCyzNQM872QI11xilaBAEbqhNfnjepIE6U7ar8SyX2TnEi7vw/J0Ex4w3PMu CYC/JZeRQxCh30oimcZFQWHsC5lbNvdyUzg1T1xGJvE1TDXkWLorGw9hkFZ/kjZW zjto/CtyfXgNo9VwNWZuH6JckNShG/k2nraYNfjcmbEUlyyJkE/xVG0u2rXg1XO3 KHNqegvWfyRv4+pxbdPYQ/A+UmVaBnrwosTzMmOrtWXYQzYoT+SYCHjugdLyoP7l 7Indj4SoOKMFz4FilYDb98JOiU/NUtuGvMk34Q+ugbCsoRRcxx5oioNhs0IDpvaz TPbNlhBMb1mvoz6/CHkoditwCrsjzidbj8m7Mdx8P2KSx2k+SVm4+A5T+NnxCPb7 77em0xfs+GWzbpLJPPXqgwjnxJv6voQFUpiZMSBOYwUeYYfJIU7FPnriEMW+Pqu9 xuEQJNO16mRlotD/gUnl =ppUO -----END PGP SIGNATURE----- </pre> Kurt Seifried 2012-05-23T18:17:38 http://permalink.gmane.org/gmane.comp.security.oss.general/7744 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2012 06:13 AM, Filippo Cavallarin wrote: Castello 2005, 30122 Venezia Can you confirm that the config.php has sensitive information within it? - -- 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/ iQIcBAEBAgAGBQJPvShPAAoJEBYNRVNeJnmTn7wP/RQ3HePcA+MniyxdVxad8XIJ Lui61HW0cEOeK7vPx+5D1KBdV09U4P9wI/73ql1lvFo2OvtqsyNEQLn0JBXgBdHv ybKi6obhk374xmr+zlWMBbt983S/A4BxuYFWuU0dCQA6jm7rAM1wQRutuBSIdzx8 3iLQr/LVAHkJFxKIjHvpZerDHW+Nh/+SLS2cMLDBXNGFnhJD1RyJlT4ZDgszdyFW A6sKwz+O4p4L3XIcLjHjzwiwBcirzzyBphY/bh/b+WTsAM3IbDHrNcAl5nUyAKBf 6M+Up8LhFDLlEzHqLHQUr3fenAxVrz4PHS1RGlspeE8jWCz/FtnFbWxqYiTDvTUi JbJpB33bVmM8NEdZds9hF+y+h0TyF0Y2JadU3fAdbLaMnWQyH6lxNYntQnWoEOI1 KGKzP3vVPdFwyXIa2PWfiz9EHrFOScH/fXMX65e3pybxMHvUyisnJNw/khBImQLW BRu0Lh+cVvsUwkr0tX/GxmbeR7pVakgcRp09ihGto7CwtIXOpEJ4pqrqCjHJRKM+ vJ7HUR72cuGriAaHrAwPWGu2UM8G7niXerGrn6YBcRos3zgIIMa9YKQCVqR8DhLd NH9WH4vhgF1cMHRaU6Az2uZx34nWYGNw59x2eO6H6uRWrN6cREVhxTXf6QtQOv4m wrTY5Ael++jgxy7++Pjq =j8ar -----END PGP SIGNATURE----- </pre> Kurt Seifried 2012-05-23T18:11:27 http://permalink.gmane.org/gmane.comp.security.oss.general/7743 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2012 11:37 AM, Vincent Danen wrote: Please use CVE-2012-2391 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/ iQIcBAEBAgAGBQJPvSeiAAoJEBYNRVNeJnmTFTwP/0gQi4YSBbmGuUlRsrn3bl1b VQV1kO0Ipk2vq2fsG7FEhwnobS8KWlYRHU8UGfgbCjPjAKRwkE0y5m59GeauND+e PMKYMLGuvEKY42kxgS6A3FsfAnWO6dyNtxTkCM/HnCmKuXoOpQAcx6cj26UlECvf Lu+3GOcYwyZJqevgW7dI2YUtNxvwYuQOUtOd0ha/XW0MXmvRhlRdu/+9C1ait1wG VIcbrlU0oGGmJR/0nG5S6ajrjf0vPHcNlDOL/fNLZqrkf//Pjvm9ozGKwyRHDSnj JplRrchBSBBGyP383vOYF5/7RL0ZL6r+XfJrs7fUGXuVcNmA5GpQNVV03DuzFs0e FNWqUROjcCWGJJHsB3Ks2WNmLfoj5OM7Pf/1rTteCCgI3qZ/hEXHc8pK2W/Hd4pu hifcx53J9UEZ8HqpKhjAxNGhpuJ7ZReXaF4diKFMue2fZIFCJMtOmB1Epr2WHi1A ym1n+nTz+lrMhbFBJiHdgx/KhPlxOxAWD9X34ENLR+emViSO4KwOpgmP0SnbiyNR MW4HjInUfb2UclBhDqJclPm+2D5xLMH23VIOMk8g7cvPheVJ+Qu7P2hmTuKaAs/Y pGkV/Cc7jiXaMmfFocYnhjhZtNO9pU8V4aq3/xxgUG32Rm8cUmEyyb4CieYIOcEI nbTapWRRQHCDY93/3fD8 =2CdO -----END PGP SIGNATURE----- </pre> Kurt Seifried 2012-05-23T18:08:34 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.oss.general