Much earlier, a design decision was made that the permission model
should not prevent following symbolic links to presumably inaccessible
locations. Recently, after some back and forth, it had been decided that
it is indeed a vulnerability that symbolic links, which currently point
to an accessible location, can potentially be re-targeted to point to a
presumably inaccessible location. Nevertheless, months later, no
solution has been found and the issue is deemed unfixable in the context
of the current permission model implementation, so it was decided to
disclose the vulnerability and to shift responsibiliy onto users who are
now responsible for ensuring that no potentially dangerous symlinks
exist in any directories that they grant access to.
I believe that this design issue might be surprising and that it comes
with significant security implications for users, so it should be
documented.
Original vulnerability report: https://hackerone.com/reports/1961655
PR-URL: https://github.com/nodejs/node/pull/49154
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
As a side effect of 205f1e643e, Node.js
now resolves some paths differently when the permission model is
enabled. While these are mostly edge cases, they are worth mentioning in
the documentation. This commit also adds a known_issues test that
demonstrates one such difference.
PR-URL: https://github.com/nodejs/node/pull/49155
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
When the experimental permission model is enabled, the running
JavaScript code is subject to certain restrictions, all of which can
be bypassed or even disabled by native code due to the nature of the
permission model implementation. That is why Node.js native addons
are disabled by default when the permission model is enabled. However,
the built-in crypto, https, and tls modules still allow loading
custom OpenSSL engines. Because OpenSSL engines can execute arbitrary
(native) code while being loaded by Node.js, this has the same security
implications as allowing native addons. In other words, allowing user
code to load OpenSSL engines at runtime effectively enables bypassing
any supposed security restrictions.
This patch adds appropriate checks before attempting to dynamically
load an OpenSSL engine that throw an error if the permission model is
enabled.
PR-URL: https://github.com/nodejs-private/node-private/pull/409
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-30586
RafaelGSS