SQLCipher for Android - 3.1.0 - Veracode scans show Medium violations for CWE ID 117 - Improper Output Neutralization for Logs - How to respond?

[Simon Tse]

Hello. I have been using SQLCipher for a while but have in recent times had to submit my code through Veracode scans to check for security levels. I got a bunch of medium violations that I am on the hook for fixing. The description is as such

Improper Output Neutralization for Logs (CWE ID 117)(17 flaws) 

Description

A function call could result in a log forging attack. Writing unsanitized user-supplied data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. 

• net/.../database/SQLiteCursor.java 591
  
• net/.../SQLiteDatabase.java 404
• net/.../SQLiteDatabase.java 505  
  
• net/.../SQLiteDatabase.java 881
  
• net/.../SQLiteDatabase.java 1489
  
• net/.../SQLiteDatabase.java 1528
  
• net/.../SQLiteDatabase.java 1631
  
• net/.../SQLiteDatabase.java 1634
  
• net/.../SQLiteDatabase.java 1773
  
• net/.../SQLiteDatabase.java 1780
  
• net/.../SQLiteDatabase.java 1892
  
• net/.../SQLiteDatabase.java 2096
  
• net/.../SQLiteDatabase.java 2118
  
• net/.../SQLiteDatabase.java 2128
  
• net/.../SQLiteDatabase.java 2157
  

I also found another which is

External Control of File Name or Path (CWE ID 73)

• net/.../SQLiteDatabase.java 414 x2 
  
• net/.../SQLiteDatabase.java 885 
  

There is more that I found. What I am wondering is what is the SQLCipher's position on these are are these things they can be changed?

Simon

[Simon Tse]

The thing that I find really difficult is that these are just regular Android Log messages and also regular ways of getting a File and deleting it. I don't event know how I would have to change it so that it passes veracode scanning.

[Nick Parker]

Hello Simon,

These log statements are intended to be there. There has been an effort
[1] to redact any sensitive information from any logging within the
library, but there is no plan to remove these statements. Should you
need to, you could certainly remove these statements and compile the
library yourself.

[1]
https://github.com/sqlcipher/android-database-sqlcipher/commit/701fc6e02f97fe7b98860c330330689063468136

On 11/21/14 2:00 PM, Simon Tse wrote:
> Hello. I have been using SQLCipher for a while but have in recent times
> had to submit my code through Veracode scans to check for security
> levels. I got a bunch of medium violations that I am on the hook for
> fixing. The description is as such
>
> Improper Output Neutralization for Logs (CWE ID 117)(17 flaws)
>
> Description
>
> A function call could result in a log forging attack. Writing
> unsanitized user-supplied data into a log file allows an attacker to
> forge log entries or inject malicious content into log files. Corrupted
> log files can be used to cover an attacker's tracks or as a delivery
> mechanism for an attack on a log viewing or processing utility. For
> example, if a web administrator uses a browser-based utility to review
> logs, a cross-site scripting attack might be possible.
>

> * net/.../database/SQLiteCursor.java 591
> * net/.../SQLiteDatabase.java 404
> * net/.../SQLiteDatabase.java 505
> * net/.../SQLiteDatabase.java 881
> * net/.../SQLiteDatabase.java 1489
> * net/.../SQLiteDatabase.java 1528
> * net/.../SQLiteDatabase.java 1631
> * net/.../SQLiteDatabase.java 1634
> * net/.../SQLiteDatabase.java 1773
> * net/.../SQLiteDatabase.java 1780
> * net/.../SQLiteDatabase.java 1892
> * net/.../SQLiteDatabase.java 2096
> * net/.../SQLiteDatabase.java 2118
> * net/.../SQLiteDatabase.java 2128
> * net/.../SQLiteDatabase.java 2157

>
> I also found another which is
>
> External Control of File Name or Path (CWE ID 73)
>

> * net/.../SQLiteDatabase.java 414 x2
> * net/.../SQLiteDatabase.java 885

>
> There is more that I found. What I am wondering is what is the
> SQLCipher's position on these are are these things they can be changed?
>
> Simon
>

> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "SQLCipher Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sqlcipher+...@googlegroups.com
> <mailto:sqlcipher+...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Nick Parker

[Simon Tse]

Thanks Nick for the quick reply.

I was thinking the same thing about doing that. Ideally of course I wouldn't have to touch any code because when I need to update the library from 3.1 to 3.2, I would have to go back into the again and remove the logs. 

For logs, I could just recompile myself. But there are other violations that aren't as easy to remove because the touch on some logic.

Crappy that Veracode seems to identify the problems but don't really show how to modify the code so that it passes criteria. We had tried to make changes before, but Veracode didn't think it was good.

[Hans-Christoph Steiner]

Sounds like that security warning is really about doing standard user input
sanitizing on anything that is output to the log. For Android, this seems
really pedantic. It sounds like they just took their web dev scanning
messages and applied them to Android.

That said, the easiest route here is to just make a function to sanitize user
input for log messages, and apply that everywhere Veracode wants you to. Then
submit that as a pull request to SQLCipher. Then no one will have to deal
with it again.

In my experience with static code analyzers, fixing trivial issues like this
can sometimes improve the results of the scan, so it could be also worthwhile
from that point of view.

.hc

Simon Tse:

>>> an email to sqlcipher+...@googlegroups.com <javascript:>
>>> <mailto:sqlcipher+...@googlegroups.com <javascript:>>.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Nick Parker
>>
>>
>

--
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81