[Interest] QML preprocessing

Roland Hughes roland at logikalsolutions.com
Mon Apr 29 00:46:11 CEST 2019

On 4/28/19 5:14 PM, Konstantin Tokarev wrote:
> 28.04.2019, 21:27, "Roland Hughes" <roland at logikalsolutions.com>:
>> On 4/28/2019 11:31 AM, Konstantin Tokarev wrote:
>>>   28.04.2019, 19:15, "Roland Hughes" <roland at 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


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.

User limits - limit the use of system-wide resources.

       ulimit [-acdfHlmnpsStuv] [limit]

    -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)

More information about the Interest mailing list