Date: Sun, 8 Feb 2015 20:06:28 -0500 (EST) From: cve-assign@...re.org To: steffen.roesemann1986@...il.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE-Request -- eFront v. 188.8.131.52 build 18021 (Community Edition) -- Multiple CSRF vulnerabilities -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I found multiple CSRF vulnerabilities ... Use CVE-2015-1559 for all of the CSRF vulnerabilities. > The components being used for creating the auto-login token are the > following informations: > > - a salt > - the accounts creation date > - the username > > The salt isn't generated dynamically during the installation. On a common > eFront installation without any changes by the administrator, it has the > value cDWQR#$Rcxsc. The admin accounts creation date has the standard value > 1365149958. > > As the standard administrators accountname is "admin", the auto-login token > for the administrators account of eFront has always the value > eb514ea3c45d74a1218e207fb4b345b1 if the precondition is fulfilled This token-creation approach is arguably an undesirable behavior, but it does not have a CVE ID. The existence of the eb514ea3c45d74a1218e207fb4b345b1 value does not provide access unless an autologin=1 request is sent within an administrative session. This issue is relevant mainly when a CSRF vulnerability exists. http://forum.efrontlearning.net/viewtopic.php?f=15&t=1940 says: Admin->Maintenance->Autologin. This new tab allows to select the users that may autologin to the system via a simple link. Useful for guest users but there are many others uses as well. We do not think that intentionally setting up Autologin for an administrator is a common or plausible use case. If Autologin had been enabled for any other user account, the attacker would apparently need to know both the username and the account's creation date. Better salting would be an opportunity for security improvement. Accounts that would realistically be configured for Autologin are probably not high-value accounts, and the salt choice could be a security-versus-complexity tradeoff. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJU2AdKAAoJEKllVAevmvmsTisH/1804w9XOS7LDUSUyqCesVEW El947wjDDb4gSQqfDX76cN0BOUahGjrJgj+9+qd+7H743UqJrV7784eBvGMa6O43 81WkQGEBqokKAr1FB0YWry2EkFsmUVpudca0Zd8nOL6WhRIJN/mG9w20AUn0TEGU nwYzehGe46gg14jkUNt1vyI4YyFtIhQATByjBUFfaSijLFf5z50UMlVS568sqOuP dsmYEOrni6hcDiKYVkFR1EQYavBvBnE0MZbCQ7j4YVuqU83QVQX4H2EyFIUpHRwM AFGkC8jGeQdNKti5YTKyUTl9EJOqi+ncCvPpLMIWYxMCGPg+Duti7Knq8xwJ6Tc= =g6vC -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ