There were multiple CVEs in previous versions of OBM (typical
web/PHP/input santizing issues: XSS, SQL injection), mostly affecting
previous 1.x series, what steps are taken in the package to ensure the
scripts aren't publicly exposed?

I would expect OBM to only be used by some key people in a company, from the 
company intranet, and with login/password; would I have to configure a SQL/PHP 
app, I might:
- restrict access to the service by IP address
- add some web server/Apache level filtering (e.g. require HTTP auth, or SSL 
client certs)

Grepping the source, I didn't see much escaping going on; nor
parametrized SQL queries.  I only found some stripslashes() and single
quoting which is rather light.

I also looked for command executions from the PHP scripts, and found that the 
LDAP password will be updated by exec()ing $path/../auto/changePasswd.pl, is 
this mode of operation supported in the .deb packages?  It seems the password 
is passed on the command line:
        $cmd = $cmd_ldap_passwd.$parameters.' --login '.$login.' --domain 
'.$domain_id.' --type '.$password_encryption." --passwd '".$new_pass."' 
--no-old";
this allows local users to see the new password.

I was a bit scared to see what other commands are defined:
// Automate commands
$cmd_halt = "sudo /sbin/halt";


As I understand it, if you install the package it will immediately be available 
from the web at /obm with login/password admin/admin.  Shouldn't there be some 
debconf prompting to ask for an admin password before putting the service up?

-- 
MIR for obm
https://bugs.launchpad.net/bugs/259776
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to