On 4/28/19 5:14 PM, Konstantin Tokarev wrote:
28.04.2019, 21:27, "Roland Hughes" <rol...@logikalsolutions.com>:
On 4/28/2019 11:31 AM, Konstantin Tokarev wrote:
28.04.2019, 19:15, "Roland Hughes" <rol...@logikalsolutions.com>:
If you are worried about a sensitive value being memory dumped because
of a completely insecure scripted language, then don't do it there.
If some data is copied to memory it can be dumped from there, no matter
what language are you using. There are no "secure" and "insecure" languages
in this regard.
Sure there are.
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/protect-secrets.html
https://www.oreilly.com/library/view/secure-programming-cookbook/0596003943/ch01s09.html
Most importantly, by placing all of the sensitive data used only for
debug in C++ class methods bounded by #ifdef DEBUG statements, in a
production release the copy will never happen.
The scarier architectural problem with the original post is the
console.log() call is calling something to convert a password to "free
text" rather than dumping a hashed/encrypted version. Most production
applications never bother with this. They compare a hashed/encrypted
version of the entered password with the hashed/encrypted version stored
on disk.
Scripted languages are inherently insecure. With QML and JavaScript you
end up with stuff like this in your elf binary.
DefaultButton {
id: helpButton
text: qsTr("Help")
iconSource: helpButton.pressed ? "/Images/help_pressed.png" :
"/Images/NewButtonIcons/help_notpressed.png"
iconSizeX: 17
iconSizeY: 24
onClicked: {
popupHelpInfo.open()
popupHelpInfo.forceActiveFocus()
}
I found that in a few seconds with Eclipse. Any number of "text" editors
will let you open and view binaries. The amount of code and logic
actually exposed to anyone willing to edit a copy of the file is
immense. Not so with compiled C/C++ or even COBOL for that matter. If
you are really worried about things like "Password" being found you have
multiple options.
1) Under Qt use tr("1234") and always have a translation file, even for
your native language.
2) Under any compiled language build the string programatically from Hex
strings. FWIW, the Hex values for "Password" are 50 61 73 73 77 6F 72 64
With a scripted language there is little you can do to avoid exposing
your code. Yes, there is an option to "precompile" QML but it comes with
significant limitations.
https://doc.qt.io/qt-5/qtquick-deployment.html
The most significant of which is being tightly bound to the version of
QML compiled against. For an embedded system where you control the
universe this could be acceptable. For an app which anyone can download
and run it is not. If you developed under 5.2 and didn't use anything
which disappeared in 5.12 you still want the user to be able to run your
app. The inverse is true as well. Just because you used 5.12 doesn't
mean you used something which only existed in 5.12.
Under various operating systems (OpenVMS in particular) one can tell the
compiler for the language of choice to place all string constants within
a single PSECT or a series of them. In your linker options the named
PSECT(s) can be flagged with an attribute which excludes them from dump
utilities. These principals have been around since the 1980s when I
started programming commercially on big-boy systems. Didn't matter if we
were working in COBOL, FORTRAN or BASIC, we always had linker option
files to flag string constant PSECTs as nodump. Even if the midrange or
mainframe was air-gapped from the world we still did this. Back then we
were only worried about dial-up access, the Internet did not exist in
any meaningful way.
With a scripted language you cannot do this. You are at the mercy of the
engine.
It would be interesting to see just how much text survives in
pre-compiled QML. I would imagine it is a lot. If the QML engine is
OpenSource then it isn't a difficult task for someone intent on gaining
passwords via a dump or cache file on disk to find the text "Password"
and decompile everything around it. They can't get back to the original
source, but they can get close enough.
Basically, if your application must be secure you cannot use a scripted
language.
You are trying to defend security through obscurity here. If attacker can
directly
dump memory of the process, game is over, and it's not principal how much work
is needed to decompile code (which may not be needed at all, depending on data
or source leaks or other possible scenarios)
You didn't bother to read anything, choosing to continue in ignorance.
There is nothing "obscurity" about tagging a PSECT nodump. This can only
be done with 3GL and lower languages. No process on the system,
including the kernel, can or will dump it.
Placing the debug printing of sensitive things like passwords inside of
3GL methods bounded by
#ifdef QT_DEBUG
should have never done it stuff here
#endif
Is not "security through obscurity." It's ensuring a non-debug
production build doesn't even include it.
These are Data Processing 101 level concepts. I'm sorry you have trouble
with them.
A scripted language cannot, under any circumstances, be made secure. You
do not have access to PSECT tagging.
You certainly didn't read anything the first link had to say. And you
certainly didn't bother to look up ulimit.
ulimit
User limits - limit the use of system-wide resources.
Syntax
ulimit [-acdfHlmnpsStuv] [limit]
Key
-S Set a soft limit for the given resource
-H Set a hard limit for the given resource
-a All current limits are reported.
-c The maximum size of core files created.
Welcome to IT in the real world. Development doesn't use scripted
languages for anything which actually matters.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
