[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#779569: addToJavaScriptWindowObject exports QObject's slots by default



Source: qtwebkit-opensource-src
Version: 5.3.2+dfsg-3
Severity: normal

Hello,

http://doc.qt.io/qt-5/qwebframe.html#addToJavaScriptWindowObject
describes how to export QObjects to JavaScript, so that properties and
slots are automatically exported, and that is cool. However, QObject
(and all its descendants) has a deleteLater() slot, which (I verified)
also gets automatically exported to JavaScript. I can call it from JS
and segfault everything.

There seems to be no way from JS to invoke functions from a carefully
crafted API so that JavaScript cannot do damage. The "Internet Security"
bit of http://doc.qt.io/qt-5/qtwebkit-bridge.html is quite limited, and
the way I read it, it seems to imply that the usafe bits come from
exporting too much, not from exporting objects at all. I would think
that with that slot exported, exporting anything is already too much.

I haven't checked if the objectName property is also exported and
writable: if that is the case, that could be another potential attack
vector.

I would expect to either see this situation documented clearly in
"Internet Security", or to have QObject's own signal and properties NOT
exported by default.


Thank you for your work on maintaining Qt!

Enrico


P.S.
I leave it up to you to decide on the severity of this bug: it could go
from critical to wishlist according to how this feature is currently
being used by other software.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


Reply to: