[Interest] QML preprocessing

[Konstantin Tokarev]

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)

-- 
Regards,
Konstantin