Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. --Tobias On 8/10/2013 7:25 AM, Reindl Harald wrote: Am 10.08.2013 12:10, schrieb Gichuki John Chuksjonia: One thing u gotta remember most of the Admins who handle webservers in a network are also developers since most of the organizations will always need to cut on expenses, and as we know, most of the developers will just look into finishing work and making it work. So if something doesn't run due to httpd.conf, you will find these guys loosening server security, therefore opening holes to the infrastructure. i am one of the developers who are admin why? because maintaining servers where only internal developed software gives you the power to make security as tighten as possible - and yes security is *always* first not the admins which are developers are the problem crap like wordpress, joomla, phpBB is the problem because these developers have no idea how to secure maintain a server and try to develop software which can be installed by any random fool on whatever webserver without understand the implications thats's why these applications are *strictly* forbidden on any machine i am responsible for, it's enough to write abuse mails each time one of these installations outside got hacked and is starting attacks on 3rd parties
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
... ciao: : on 8-10-2013 Gichuki John Chuksjonia writ: : most of the Admins who handle webservers : in a network are also developers name , just a few : most of the organizations will always need to cut on expenses, history suggests, security breaches, are NOT a profit center. : and as we know i'd prefer, that you not include me in that knowledge base. things like: : most of the developers will just look into finishing work and : making it work AND : So if something doesn't run due to httpd.conf, you will find these : guys loosening server security, therefore opening holes to the : infrastructure AND : From: guess who NotMyDomain @ gmail.com do not typically inspire confidence, or the illusion of a working knowledge about the subject at hand. on a parallel track. i'm a ham, WD0FPC, and every so often a new operator, sets about becoming an expert, offering their two cents worth. i am yet to see a case in which it didn't go one of three ways; (a) left the hobby, (b) became an operator worthy of license class, and (c), didn't. computing, and amateur radio, both the classic 'community', with knowledge as lifeblood, and the willingness to help its life energy. in some schools of thought, both individually, and collectively, a deserved respect inherent. solidified ignorance, flawed assumptions, and faulty logic, able to ignore all that. for a while ... -- ... it's not what you see , but in stead , notice ...
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout On 8/10/2013 7:25 AM, Reindl Harald wrote: Am 10.08.2013 12:10, schrieb Gichuki John Chuksjonia: One thing u gotta remember most of the Admins who handle webservers in a network are also developers since most of the organizations will always need to cut on expenses, and as we know, most of the developers will just look into finishing work and making it work. So if something doesn't run due to httpd.conf, you will find these guys loosening server security, therefore opening holes to the infrastructure. i am one of the developers who are admin why? because maintaining servers where only internal developed software gives you the power to make security as tighten as possible - and yes security is *always* first not the admins which are developers are the problem crap like wordpress, joomla, phpBB is the problem because these developers have no idea how to secure maintain a server and try to develop software which can be installed by any random fool on whatever webserver without understand the implications thats's why these applications are *strictly* forbidden on any machine i am responsible for, it's enough to write abuse mails each time one of these installations outside got hacked and is starting attacks on 3rd parties -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On 2013-08-11 Reindl Harald wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Most developers I have met would focus on getting new features to work rather than secure/reliable operation of the deployed software. bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout Apparently you still haven't learned your lesson from being banned from the postfix-users mailing list. Regards Ansgar Wiechers -- All vulnerabilities deserve a public fear period prior to patches becoming available. --Jason Coombs on Bugtraq
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
for doing this features in httpd.conf you can use AllowOverride None instead of AllowOverride all AllowSymlinks is a red herring here (hardlinks should do, unless you have stuff partitioned in a very thoughtful way, which most don't), similarly to suexec. In general, sharing web hosting providers that allow shell access or scripting are pretty much boned in a myriad of ways. /mz
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 11.08.2013 14:50, schrieb Ansgar Wiechers: On 2013-08-11 Reindl Harald wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Most developers I have met would focus on getting new features to work rather than secure/reliable operation of the deployed software maybe you met the wrong ones on the other hand most admins i met did not use disallow_functions a responsilble developer which is at the same time admin has the knowledge not using dangerous functions and disables them one config line and the whole topic would be obsolete by not allowing symlinks from web-applications disable_functions = popen, pclose, exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice, proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, mail, symlink, link, dl, get_current_user, getmypid, getmyuid, getrusage, pfsockopen, socket_accept, socket_bind, openlog, syslog bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout Apparently you still haven't learned your lesson from being banned from the postfix-users mailing list oh i forgot, in the enlish speaking world in have to write clould i ask you please could consider to think about signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Agreed. Many sites limit users to at most SymLinksIfOwnerMatch for that very reason, not to mention limits on CGI privileges. AllowSymlinks, IMO, ought to be reserved for the sysadmin on the server and used sparingly. You can, of course, even require .htaccess configurations to be set in the server's configuration files instead of in the user account areas (in conjunction with the AllowOverride None setting). --Tobias On 8/11/2013 7:52 AM, Michal Zalewski wrote: for doing this features in httpd.conf you can use AllowOverride None instead of AllowOverride all AllowSymlinks is a red herring here (hardlinks should do, unless you have stuff partitioned in a very thoughtful way, which most don't), similarly to suexec. In general, sharing web hosting providers that allow shell access or scripting are pretty much boned in a myriad of ways. /mz
[SECURITY] [DSA 2736-1] putty security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-2736-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso August 11, 2013http://www.debian.org/security/faq - - Package: putty Vulnerability : several Problem type : local (remote) Debian-specific: no CVE ID : CVE-2013-4206 CVE-2013-4207 CVE-2013-4208 CVE-2013-4852 Debian Bug : 718779 Several vulnerabilities where discovered in PuTTY, a Telnet/SSH client for X. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2013-4206 Mark Wooding discovered a heap-corrupting buffer underrun bug in the modmul function which performs modular multiplication. As the modmul function is called during validation of any DSA signature received by PuTTY, including during the initial key exchange phase, a malicious server could exploit this vulnerability before the client has received and verified a host key signature. An attack to this vulnerability can thus be performed by a man-in-the-middle between the SSH client and server, and the normal host key protections against man-in-the-middle attacks are bypassed. CVE-2013-4207 It was discovered that non-coprime values in DSA signatures can cause a buffer overflow in the calculation code of modular inverses when verifying a DSA signature. Such a signature is invalid. This bug however applies to any DSA signature received by PuTTY, including during the initial key exchange phase and thus it can be exploited by a malicious server before the client has received and verified a host key signature. CVE-2013-4208 It was discovered that private keys were left in memory after being used by PuTTY tools. CVE-2013-4852 Gergely Eberhardt from SEARCH-LAB Ltd. discovered that PuTTY is vulnerable to an integer overflow leading to heap overflow during the SSH handshake before authentication due to improper bounds checking of the length parameter received from the SSH server. A remote attacker could use this vulnerability to mount a local denial of service attack by crashing the putty client. Additionally this update backports some general proactive potentially security-relevant tightening from upstream. For the oldstable distribution (squeeze), these problems have been fixed in version 0.60+2010-02-20-1+squeeze2. This update also provides a fix for CVE-2011-4607, which was fixed for stable already. For the stable distribution (wheezy), these problems have been fixed in version 0.62-9+deb7u1. For the unstable distribution (sid), these problems have been fixed in version 0.63-1. We recommend that you upgrade your putty packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCgAGBQJSB+lQAAoJEHidbwV/2GP+6HUQAIGHk0ctuvUFNpPgZtZwGA9W iX2oysndnZLXZmc1zkXhwvPo5fg/+PjdOvYn0cHfrgVb2wXMPAwIAjUwTZ+p2SbF PwaXbjUr3sUJxQLdFoGNytfFeiUtQNj0/r/ylmQB77bgFKSI9iFnveYeNKc51Shb ApaFKIueuYgrPUTt8KquloNvNryuLa0AjhveWsIDdFQVGW6ipAe70T2BohX5QIwh ehzom1sFbEgJpqdPUt6sR7vyBj+mhg9atp3wCQkEJFq5uhrDEL6OrCwpZJ1oClMP a0LSPwESz4iWUzL3eTgB7ENIcAelBQ4LWnVhuTxpaRGoHizmkId6ueMBD9ezJrmH +/vDsBMQLxZuWP1SG7rEoEjJTsJEVQ/D7vu+s6cDuiliOr8IJ/2oXy0WQCDxinCI l7iJaCQcxcGWY5LmW9tO94GW6ptSUW4aROKLt12u1X4VkKjLpyzkGWNNvK4H6vHg 6orNaN8evpEVjj9ZF7Gq93e79ldhSjuj7ZZPcWmZNHdefxT+wxuXUB7flTXSRhlk RaTC5SrqRlmGSUkm0HaRc61iTh/VZbj1Zw+M+mNw1VwTTUbFOH7gWThkbjWr/yC1 HJpGe4Cpdm+289ci50Z/IVC7rKe0QsGW4tvpeS3N3lsvEVLj/skg/UIAnr86zU65 1VnEAudwqB82viZ0ci+C =nzel -END PGP SIGNATURE-
