doc: document dangerous symlink behavior #49154
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Review requested:
|
RafaelGSS
reviewed
Aug 14, 2023
|
Hey @tniessen, do you know some help on this? Feel free to ping me. |
|
I think it's technically correct as it is, but I'll rephrase it. |
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
tniessen
force-pushed
the
doc-symlink-danger
branch
from
05b0b7b
to
1fd427b
Compare
|
@tniessen the content of that report was closed as "informative", based on what it was discussed at length this is a limitation of the current system, and not a vulnerability that is solvable without some significant redesign, and better handled in public vs private doors. Therefore, no, that's not really a vulnerability per our processes. Could you amend the PR description? |
|
@mcollina I have updated the PR description. Let me know if anything in there is untrue. For what it's worth, there was agreement that this is a vulnerability. The reason for not following our usual vulnerability procedures was not a reassessment of the issue, but the inability to fix it even after months. |
benjamingr
approved these changes
Sep 23, 2023
tniessen
added
the
author ready
aduh95
approved these changes
Sep 29, 2023
tniessen
added
the
commit-queue
nodejs-github-bot
removed
the
commit-queue
|
Landed in 1dc0667 |
alexfernandez
pushed a commit
to alexfernandez/node
that referenced
this pull request
Nov 1, 2023
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: nodejs#49154 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
targos
pushed a commit
that referenced
this pull request
Nov 11, 2023
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: #49154 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
debadree25
pushed a commit
to debadree25/node
that referenced
this pull request
Apr 15, 2024
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: nodejs#49154 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
vulnerabilitypeculiarity 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