gilzoide
Issues raised by JFrog scan
Hello,
I'm using your package in a cross platform project for Android and iOS devices. Everything works as expected, but when I scanned the app with JFrog scanner it found some issues. I'm not sure if those are just in SQLite native code or not. I only see those problems with android build. iOS is just fine. The problems are found in arm64-v8a/libgilzoide-sqlite-net.so and they are:
CWE-476 - DAT_0028a488 = getenv("TMPDIR");
CWE-476 - DAT_0028a488 = getenv("SQLITE_TMPDIR");
CWE-835 - ppuVar1 = (undefined **)"insert"; if ((param_1[1][1] & 4U) != 0) { ppuVar1 = (undefined **)&DAT_00119781;
CWE-835 - cVar4 = *(char *)((long)param_1 + 199);
CWE-835 - iVar10 = 0;
CWE-835 - ppbVar68[6] = (byte *)ppbVar31;
I suppose that it might just say you nothing, so please let me know what would be more informative to you. I tried replacing the .so file with the precompiled version from SQLite website, but it didn't work (the app started crashing as soon as I try to use SQLite).
Hey @Wasp3r, thanks for the report.
The SQLite amalgamated code is downloaded directly from https://sqlite.org/download.html and is unchanged in this package. The only native code in this shared library is SQLite code itself, with exception of the WebGL build that has the addition of idbvfs, the VFS backed by Indexed DB.
Did you pass the source code through JFrog scanner or only the prebuilt Android binary?
Btw, CWE-476 means "Null Pointer Dereference" and CWE-835 means "Loop with Unreachable Exit Condition, a.k.a Infinite Loop", I had to look those up.
Thank you very much for your response,
If this is unchanged, then we probably can't do anything about it. I thought those might be some of your changes, as in the documentation you mentioned some modifications to SQLite source code. I guess now we can either accept it or step back from SQLite completely.
I scanned the whole built .apk file with JFrog. I think it unpacks everything to scan it. I don't have any experience with it, so I'm not sure.
Sorry I didn't describe what those CWE errors mean, I could have done that and save you a bit of research.
Have you tried running the scanner through the source code? Or through the shared libraries themselves? The arm32 as well as the arm64?
If you don't trust the prebuilt binaries, you can always compile them yourself. The Makefile is quite straightforward, you just need to setup the ANDROID_NDK_ROOT and run make all-android. There's also a Dockerized build target, make docker-all-android.
Sorry I didn't describe what those CWE errors mean, I could have done that and save you a bit of research.
No problem, it was really easy to find out, sorry if I sounded rude or anything like that.
Maybe these issues are false positives. If you look for "TMPDIR" and "SQLITE_TMPDIR" in SQLite's source code, you'll see that indeed there's a call to getenv and a pointer dereference in the same line, but the pointer of the env itself is not dereferenced, it's another one (azTempDirs). There will never be a null pointer dereferenced in this case, azTempDirs is a static array and will never be null.
The other ones are quite hard to find the source code for. Looking for "insert" the only place I found it is inside jsonSetFunc, where the string participates in a ternary operator, not sure if it's it. It's not really called in a loop as far as I can tell, it's function pointer is used in a loop though (in the call to sqlite3InsertBuiltinFuncs withing sqlite3RegisterJsonFunctions).
I'll request the scan of the source code and the shared libraries. Maybe there was some issue with build settings.
Thank you so much for your insight about the bugs too, this is very helpful. I'll let you know once the scans will pass how it went.
Thank you so much for your insight about the bugs too, this is very helpful.
No problem, I'm here to help!
I'll let you know once the scans will pass how it went.
Please do! I haven't heard of people with crashes / freezes on Android, but maybe there are, I don't know. Maybe JFrog is right, maybe the built binary is bad, although at least by reading the source code there doesn't seem to be any problem.
Hey, I'm back with the results. Sorry that it's THAT late, but the process of requesting scans and so on takes ages.
I decided I would build the source code by myself, as you suggested. You were right, it wasn't rocket sience. Though I'm not super sure about the results. The problem disappeared, but I was also informed, that this scanner has some tendencies to rise false positives. It was even marking SQLite version as some really old one, even though I saw that it's the newest possible. Because of that, I'm not sure if the fact that I re-built it helped, or was it just a false positive that didn't happen the second time. If I could run those scans by myself, I would check, but unfortunately I cannot.
Anyway, thank you very much for your help, I really appreciate it :)