View Issue Details

IDProjectCategoryView StatusLast Update
0000502SOGoBackend Generalpublic2016-12-09 10:47
Reportermaddog Assigned Toludovic  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version1.2.1 
Fixed in Version3.2.5 
Summary0000502: SQL injection vulnerabilities
Description

The backend does not use prepared statements and bind variables when performing SQL queries --- rather it constructs literal statements by interpolating variables into format strings. In doing so, few (if any?) free-form string values are properly escaped before interpolation, so the code if rife with opportunities for SQL injection attacks.

In fact, it is quite trivial, for example, to alter the database via the username field on the login/front-page. Thus, one need not even be an authenticated user to attack the system.

TagsNo tags attached.

Activities

wsourdeau

wsourdeau

2010-03-23 21:48

viewer   ~0000784

Can you provide samples of what you state above? I don't exactly see how one could inject SQL from the login form, unless the authentication is made via an SQL view...

maddog

maddog

2010-03-24 21:05

reporter   ~0000793

Yes, indeed --- SQL injection from the login form is possible when SQL authentication is being used. (Sorry I didn't say that explicitly; that's what I've been working on setting up.)

For an example, the following "Username" will delete the everything from the folder info table (given the default/suggested name and a postgresql db):

'; DELETE FROM sogo_folder_info; SELECT '1

That's the first SQL injection exploit I have ever written; I imagine people who like this kind of thing could come up with something more creative.

ludovic

ludovic

2010-03-24 21:23

administrator   ~0000794

This has been fixed for SQLSource - have you spotted any others?

maddog

maddog

2010-03-25 00:53

reporter   ~0000796

Thanks for the speedy fix.

I took another (quick) look --- basically by grepping for "sql" to look for SQL statements. I can't say I saw anything trivially exploitable, but I can't say everything else is safe, either. I don't know the codebase well enough to know, for example, what happens to a string typed in a addressbook search-bar.

Whenever I see code that does simple string-substitution to perform SQL queries, I get nervous, because such code becomes increasingly difficult to audit for such vulnerabilities over time. (And, performance tends to suck as well, because the DB has to parse/prepare/optimize each statement over and over again with every query.)

ludovic

ludovic

2016-12-09 10:47

administrator   ~0010978

340ddf0ae6cf6a7aeb16d7b77f237bee7bff16a3 contains other safe measures. Closing for now since after an audit of the code, things seem clean.

Issue History

Date Modified Username Field Change
2010-03-19 00:07 maddog New Issue
2010-03-23 21:48 wsourdeau Note Added: 0000784
2010-03-24 21:05 maddog Note Added: 0000793
2010-03-24 21:23 ludovic Note Added: 0000794
2010-03-25 00:53 maddog Note Added: 0000796
2016-12-09 10:47 ludovic Note Added: 0010978
2016-12-09 10:47 ludovic Status new => resolved
2016-12-09 10:47 ludovic Fixed in Version => 3.2.5
2016-12-09 10:47 ludovic Resolution open => fixed
2016-12-09 10:47 ludovic Assigned To => ludovic