[Interest] QML and sensitive data
René Hansen
renehh at gmail.com
Thu Sep 5 14:56:02 CEST 2019
So here's a crazy idea.
You could decide to circumvent the whole thing, by drawing your own input
widget on top of an opengl texture, and inject that into the QML
scenegraph. I'm not entirely sure how you would sidestep input handling,
but at least that way you could potentially sidestep everything in JS-land,
and keep everything in protected memory.
I think you'd be in for a world of hurt, since you have to manage all the
native interfacing yourself, but at least it's doable in theory.
/René
On Thu, 5 Sep 2019 at 09:38, Alexander Ivash <elderorb at gmail.com> wrote:
> Crashes are already happening which means obviously I'm doing
> something wrong. But what options do I have? Do I have it at all?
>
> чт, 5 сент. 2019 г. в 09:37, Elvis Stansvik <elvstone at gmail.com>:
> >
> > Den tors 5 sep. 2019 01:22Alexander Ivash <elderorb at gmail.com> skrev:
> >>
> >> Thank you for fast response, but my question is purely about QML. On
> >> C++ side I have a lot of ways for nullifying / erasing sensitive
> >> information *after* it is not needed (let say after particular QML
> >> screen gets' closed). But on QML / JS side I have no any control at
> >> all. Would be great if one of QML guys could step in and comment too.
> >>
> >> Here is the small example illustrating my issue (all I need is to make
> >> 'Piter Pen' to disappear from memory dumps):
> >>
> >> <main.qml>
> >>
> >> import QtQuick 2.12
> >> import QtQuick.Window 2.12
> >>
> >> Window {
> >> visible: true
> >> width: 640
> >> height: 480
> >> title: qsTr("Hello World")
> >>
> >> Component.onCompleted: {
> >> var test = "Piter Pen";
> >>
> >> // uncommenting results in a crash
> >> // backend.cleanup(test);
> >>
> >> // doesnt' nullify "Piter Pen"
> >> // gc();
> >>
> >> // doesn't work either
> >> /*
> >> Qt.callLater(() => {
> >> gc();
> >> })
> >> */
> >> }
> >> }
> >>
> >> <main.cpp>
> >>
> >> #include <QGuiApplication>
> >> #include <QQmlContext>
> >> #include <QQmlApplicationEngine>
> >> #include <random>
> >> #include <chrono>
> >> #include <QString>
> >> #include <QByteArray>
> >> #include <QDebug>
> >>
> >> class Backend : public QObject
> >> {
> >> Q_OBJECT
> >> public:
> >> explicit Backend(QObject *parent = nullptr) {
> >> QString str1 = "Piter Pen";
> >> QString str2 = str1;
> >> QString str3 = str2;
> >>
> >> qDebug() << "str1:" << str1;
> >> qDebug() << "str2:" << str2;
> >> qDebug() << "str3:" << str3;
> >>
> >> cleanup(str1);
> >>
> >> qDebug() << "str1:" << str1;
> >> qDebug() << "str2:" << str2;
> >> qDebug() << "str3:" << str3;
> >> }
> >>
> >> Q_INVOKABLE void cleanup(const QString& str) {
> >> std::mt19937
> >> eng(std::chrono::system_clock::now().time_since_epoch().count());
> >> std::uniform_int_distribution<ushort> distribution;
> >>
> >> QChar* data = const_cast<QChar*> (str.constData());
> >>
> >> for(int i = 0; i < str.length(); ++i) {
> >> data[i] = distribution(eng);
> >> }
> >
> >
> > Just a word of caution: Even if you had not gotten a crash, like Thiago
> said you need to be very careful here: A smart compiler could possibly
> decide that since the memory pointed to by data is not used after this, it
> can optimize this entire loop of yours away.
> >
> > Not saying that's going to happen, but you need to be very careful. I
> think there are platform specific memory-zeroing functions that could be
> used that are written with that in mind. At least I know OpenBSD has
> something like that.
> >
> >> }
> >> };
> >>
> >> int main(int argc, char *argv[])
> >> {
> >> QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
> >>
> >> QGuiApplication app(argc, argv);
> >>
> >> Backend backend;
> >> QQmlApplicationEngine engine;
> >> const QUrl url(QStringLiteral("qrc:/main.qml"));
> >> QObject::connect(&engine, &QQmlApplicationEngine::objectCreated,
> >> &app, [url](QObject *obj, const QUrl &objUrl) {
> >> if (!obj && url == objUrl)
> >> QCoreApplication::exit(-1);
> >> }, Qt::QueuedConnection);
> >> engine.rootContext()->setContextProperty("backend", &backend);
> >> engine.load(url);
> >>
> >> return app.exec();
> >> }
> >>
> >> #include "main.moc"
> >>
> >> чт, 5 сент. 2019 г. в 01:32, Thiago Macieira <thiago.macieira at intel.com
> >:
> >> >
> >> > On Wednesday, 4 September 2019 14:46:09 PDT Alexander Ivash wrote:
> >> > > Is there any mechanism for cleanup sensitive data like passwords etc
> >> > > from QML? This issue is that gc() doesn't seem to even nullify
> memory
> >> > > (at least in release on Windows) so all the sensitive information
> >> > > stays in memory.
> >> >
> >> > Write in C++ and manage your memory VERY carefully. Remember that
> memset()
> >> > before free / delete or going out of scope is removed by the compiler.
> >> >
> >> > Don't use new or malloc. Instead, mmap() your chunk of memory
> yourself and
> >> > mlock() it properly.
> >> >
> >> > Of course, to display such information you need to accept that it is
> no longer
> >> > secure. It'll go to QML, then to the text engines, then the pixels
> will be
> >> > transferred to the display server or the GPU, etc.
> >> > --
> >> > Thiago Macieira - thiago.macieira (AT) intel.com
> >> > Software Architect - Intel System Software Products
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Interest mailing list
> >> > Interest at qt-project.org
> >> > https://lists.qt-project.org/listinfo/interest
> >> _______________________________________________
> >> Interest mailing list
> >> Interest at qt-project.org
> >> https://lists.qt-project.org/listinfo/interest
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
--
Never fear, Linux is here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190905/04ce307e/attachment.html>
More information about the Interest
mailing list