Baguette/dodb.cr
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Data-leak++

Browse source
This commit is contained in:
Philippe Pittoli 2025-01-23 04:17:14 +01:00
parent 2db46f1525
commit 3109ee3bba
1 changed files with 39 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
paper/paper.ms
View file

@ -28,9 +28,9 @@
.I "\\$*"
..
.de DIRECTORY
.ps -2
.I "\\$*"
.ps +2
.ps -3
\f[CW]\\$*\f[]
.ps +3
..
.de PRIMARY_KEY
.I \\$1 \\$2 \\$3
@ -998,7 +998,7 @@ Sure, DODB isn't vulnerable to SQL injections, but an internet-facing applicatio
Of course, DODB isn't a mechanism to protect applications from any possible attack, so most of the vulnerabilities cannot be countered by the library.
However, a few security mechanisms exist to prevent data leak or data modification from an outsider and the DODB library may implement some of them in the future.
.B "Preventing data leak" .
.B "Preventing data leak with in-app memory management" .
Since DODB is a library, any attack on the application using it can lead to a data leak.
For the moment, any part of the application can access data stored in memory.
Operating systems provide system calls to protect parts of the allocated memory.
@ -1022,17 +1022,46 @@ the idea is to read (or write) memory only once you ask for it via a syscall.
Thus, you cannot access data from anywhere (by mistake or after an attack).
These mechanisms could be used internally by DODB to prevent a data leak since memory is handled by the library.
However, the Crystal language doesn't provide a way to manage memory manually and this may be a problem for mlock and mprotect\*[*].
However, the Crystal language doesn't provide a way to manage memory manually and this may be a problem for mlock and mprotect.
Depending on the plateform (the operating system), these syscalls may require the memory to be aligned with the memory pages.
Thus, the implementation won't be easy in the current state of affairs\*[*] (read: with the current Crystal's standard library).
.FOOTNOTE1
But again, the Crystal language is an implementation detail.
The working principle of DODB can be translated in basically any other language, including some enabling access to low-level memory operations.
.FOOTNOTE2
Depending on the plateform (the operating system), these syscalls may require the memory to be aligned with the memory pages.
Thus, the implementation won't be easy.
.B "Side-note. Discussion on security" .
No authorization mechanism prevents the application to access un-authorized data, including, but not limited to, any file on the file-system.
Since this implementation of DODB is related to the Crystal language (which isn't fully ported to the OpenBSD plateform at-the-moment), this is a problem.
.B "Other methods to prevent data leak" .
By default, a running application can call any syscall and open sockets or any file owned by the user.
Thus, in case a user runs an internet-facing application that is hacked, the content of any of their file can be leaked, including sensible files (in the
.DIRECTORY ~/.ssh/
directory for example).
To prevent applications from performing unwanted operations (calling syscalls or accessing some files unrelated to the proper functioning of the application), operating systems implemented specific ways to enforce security.
All of these methods have their own pros and cons.
This obviously goes beyond the scope of this document, but let's mention a few widespread mechanisms\*[*].
.FOOTNOTE1
Actual statistics on the use of the different security mechanisms is rather hard to obtain.
Both presented mechanisms are supported by a wealthy company or by the operating system itself.
.FOOTNOTE2
.BULLET "\fBAppArmor\f[] (linux):"
Linux has many mechanisms to handle software security, one of the most known is AppArmor (supported since 2009 by Canonical).
AppArmor can limit the use of syscalls and the access to files and directories.
A configuration file is used to describe what an application (defined by the path to its executable) can or cannot do; the source code of the application is left untouched.
.BULLET "\fBpledge and unveil\f[] (openbsd):"
The OpenBSD operating system includes two complementary syscalls: pledge (to allow or to deny use of syscalls) and unveil (to allow or to deny the access of directories and files).
The design of these functions is simple: applications often have an
.I init
phase during which the connections are made or files are opened (including configuration files),
then comes the
.I running
phase, during which the application needs less priviledges.
Therefore, an application can access whatever it needs for its initialization phase, then restricts its own rights over syscalls and files.
For example, a web server can read its configuration file to learn where are the files to serve, then prevents itself from accessing any other file (including its own configuration file).
Having in-app mechanisms such as these greatly simplifies the configuration; and they are even inherently safer than AppArmor and the like.
.ENDBULLET
.
.
.SECTION Real-world usage: netlib.re