pysec-2022-212
Vulnerability from pysec
Jupyter Notebook is a web-based notebook environment for interactive computing. Prior to version 6.4.12, authenticated requests to the notebook server with ContentsManager.allow_hidden = False only prevented listing the contents of hidden directories, not accessing individual hidden files or files in hidden directories (i.e. hidden files were 'hidden' but not 'inaccessible'). This could lead to notebook configurations allowing authenticated access to files that may reasonably be expected to be disallowed. Because fully authenticated requests are required, this is of relatively low impact. But if a server's root directory contains sensitive files whose only protection from the server is being hidden (e.g. ~/.ssh while serving $HOME), then any authenticated requests could access files if their names are guessable. Such contexts also necessarily have full access to the server and therefore execution permissions, which also generally grants access to all the same files. So this does not generally result in any privilege escalation or increase in information access, only an additional, unintended means by which the files could be accessed. Version 6.4.12 contains a patch for this issue. There are currently no known workarounds.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "notebook",
"purl": "pkg:pypi/notebook"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.4.12"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.0.0",
"4.0.0",
"4.0.1",
"4.0.2",
"4.0.4",
"4.0.5",
"4.0.6",
"4.1.0",
"4.2.0",
"4.2.0b1",
"4.2.1",
"4.2.2",
"4.2.3",
"4.3.0",
"4.3.1",
"4.3.2",
"4.4.0",
"4.4.1",
"5.0.0",
"5.0.0b1",
"5.0.0b2",
"5.0.0rc1",
"5.0.0rc2",
"5.1.0",
"5.1.0rc1",
"5.1.0rc2",
"5.1.0rc3",
"5.2.0",
"5.2.0rc1",
"5.2.1",
"5.2.1rc1",
"5.2.2",
"5.3.0",
"5.3.0rc1",
"5.3.1",
"5.4.0",
"5.4.1",
"5.5.0",
"5.5.0rc1",
"5.6.0",
"5.6.0rc1",
"5.7.0",
"5.7.1",
"5.7.10",
"5.7.11",
"5.7.12",
"5.7.13",
"5.7.2",
"5.7.3",
"5.7.4",
"5.7.5",
"5.7.6",
"5.7.8",
"5.7.9",
"6.0.0",
"6.0.0rc1",
"6.0.1",
"6.0.2",
"6.0.3",
"6.1.0",
"6.1.0rc1",
"6.1.1",
"6.1.2",
"6.1.3",
"6.1.4",
"6.1.5",
"6.1.6",
"6.2.0",
"6.3.0",
"6.4.0",
"6.4.0a0",
"6.4.0a1",
"6.4.0rc0",
"6.4.1",
"6.4.10",
"6.4.11",
"6.4.2",
"6.4.3",
"6.4.4",
"6.4.5",
"6.4.6",
"6.4.7",
"6.4.8",
"6.4.9",
"5.7.14a0",
"5.7.14",
"5.7.15"
]
}
],
"aliases": [
"CVE-2022-29238",
"GHSA-v7vq-3x77-87vg"
],
"details": "Jupyter Notebook is a web-based notebook environment for interactive computing. Prior to version 6.4.12, authenticated requests to the notebook server with `ContentsManager.allow_hidden = False` only prevented listing the contents of hidden directories, not accessing individual hidden files or files in hidden directories (i.e. hidden files were \u0027hidden\u0027 but not \u0027inaccessible\u0027). This could lead to notebook configurations allowing authenticated access to files that may reasonably be expected to be disallowed. Because fully authenticated requests are required, this is of relatively low impact. But if a server\u0027s root directory contains sensitive files whose only protection from the server is being hidden (e.g. `~/.ssh` while serving $HOME), then any authenticated requests could access files if their names are guessable. Such contexts also necessarily have full access to the server and therefore execution permissions, which also generally grants access to all the same files. So this does not generally result in any privilege escalation or increase in information access, only an additional, unintended means by which the files could be accessed. Version 6.4.12 contains a patch for this issue. There are currently no known workarounds.",
"id": "PYSEC-2022-212",
"modified": "2022-08-24T20:50:33.251121Z",
"published": "2022-06-14T18:15:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/jupyter/notebook/security/advisories/GHSA-v7vq-3x77-87vg"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.