data/reports: remove backticks from descriptions

Remove markdown-style backticks from descriptions that contain them,
sometimes replacing them with double-quotes where appropriate.

Change-Id: Ie8072bb2433afe540e61a35125a48ba9bff6e4df
Reviewed-on: https://go-review.googlesource.com/c/vulndb/+/549237
Reviewed-by: Damien Neil <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>

data/osv/GO-2021-0412.json

@@ -8,7 +8,7 @@
     "GHSA-8v99-48m9-c8pm"
   ],
   "summary": "Incorrect authorization in github.com/containerd/imgcrypt",
-  "details": "The imgcrypt library provides API extensions for containerd to support encrypted container images and implements the ctd-decoder command line tool for use by containerd to decrypt encrypted container images. The imgcrypt function `CheckAuthorization` is supposed to check whether the current used is authorized to access an encrypted image and prevent the user from running an image that another user previously decrypted on the same system. In versions prior to 1.1.4, a failure occurs when an image with a ManifestList is used and the architecture of the local host is not the first one in the ManifestList. Only the first architecture in the list was tested, which may not have its layers available locally since it could not be run on the host architecture. Therefore, the verdict on unavailable layers was that the image could be run anticipating that image run failure would occur later due to the layers not being available. However, this verdict to allow the image to run enabled other architectures in the ManifestList to run an image without providing keys if that image had previously been decrypted. A patch has been applied to imgcrypt 1.1.4. Workarounds may include usage of different namespaces for each remote user.",
+  "details": "The imgcrypt library provides API extensions for containerd to support encrypted container images and implements the ctd-decoder command line tool for use by containerd to decrypt encrypted container images. The imgcrypt function CheckAuthorization is supposed to check whether the current used is authorized to access an encrypted image and prevent the user from running an image that another user previously decrypted on the same system. In versions prior to 1.1.4, a failure occurs when an image with a ManifestList is used and the architecture of the local host is not the first one in the ManifestList. Only the first architecture in the list was tested, which may not have its layers available locally since it could not be run on the host architecture. Therefore, the verdict on unavailable layers was that the image could be run anticipating that image run failure would occur later due to the layers not being available. However, this verdict to allow the image to run enabled other architectures in the ManifestList to run an image without providing keys if that image had previously been decrypted. A patch has been applied to imgcrypt 1.1.4. Workarounds may include usage of different namespaces for each remote user.",
   "affected": [
     {
       "package": {

data/osv/GO-2022-0322.json

@@ -8,7 +8,7 @@
     "GHSA-cg3q-j54f-5p7p"
   ],
   "summary": "Uncontrolled resource consumption in github.com/prometheus/client_golang",
-  "details": "The Prometheus client_golang HTTP server is vulnerable to a denial of service attack when handling requests with non-standard HTTP methods.\n\nIn order to be affected, an instrumented software must use any of the promhttp.InstrumentHandler* middleware except `RequestsInFlight`; not filter any specific methods (e.g GET) before middleware; pass a metric with a \"method\" label name to a middleware; and not have any firewall/LB/proxy that filters away requests with unknown \"method\".",
+  "details": "The Prometheus client_golang HTTP server is vulnerable to a denial of service attack when handling requests with non-standard HTTP methods.\n\nIn order to be affected, an instrumented software must use any of the promhttp.InstrumentHandler* middleware except RequestsInFlight; not filter any specific methods (e.g GET) before middleware; pass a metric with a \"method\" label name to a middleware; and not have any firewall/LB/proxy that filters away requests with unknown \"method\".",
   "affected": [
     {
       "package": {

data/osv/GO-2022-0533.json

@@ -7,7 +7,7 @@
     "CVE-2022-29804"
   ],
   "summary": "Path traversal via Clean on Windows in path/filepath",
-  "details": "On Windows, the filepath.Clean function can convert certain invalid paths to valid, absolute paths, potentially allowing a directory traversal attack.\n\nFor example, Clean(`.\\c:`) returns `c:`.",
+  "details": "On Windows, the filepath.Clean function can convert certain invalid paths to valid, absolute paths, potentially allowing a directory traversal attack.\n\nFor example, Clean(\".\\c:\") returns \"c:\".",
   "affected": [
     {
       "package": {

data/osv/GO-2022-0978.json

@@ -8,7 +8,7 @@
     "GHSA-f524-rf33-2jjr"
   ],
   "summary": "Protection bypass in github.com/open-policy-agent/opa",
-  "details": "Open Policy Agent (OPA) is an open source, general-purpose policy engine. The Rego compiler provides a (deprecated) `WithUnsafeBuiltins` function, which allows users to provide a set of built-in functions that should be deemed unsafe and rejected by the compiler if encountered in the policy compilation stage.\n\nA bypass of this protection is possible when using the `with` keyword to mock a built-in function that isn't taken into account by `WithUnsafeBuiltins`.",
+  "details": "Open Policy Agent (OPA) is an open source, general-purpose policy engine. The Rego compiler provides a (deprecated) WithUnsafeBuiltins function, which allows users to provide a set of built-in functions that should be deemed unsafe and rejected by the compiler if encountered in the policy compilation stage.\n\nA bypass of this protection is possible when using the \"with\" keyword to mock a built-in function that isn't taken into account by WithUnsafeBuiltins.",
   "affected": [
     {
       "package": {

data/osv/GO-2022-1071.json

@@ -8,7 +8,7 @@
     "GHSA-f4p5-x4vc-mh4v"
   ],
   "summary": "Denial of service in flux controllers in github.com/fluxcd modules",
-  "details": "Flux controllers are vulnerable to a denial of service attack.\n\nUsers that have permissions to change Flux's objects, either through a Flux source or directly within a cluster, can provide invalid data to fields `.spec.interval` or `.spec.timeout` (and structured variations of these fields), causing the entire object type to stop being processed.\n\nThe issue has two root causes: a) the Kubernetes type `metav1.Duration` is not fully compatible with the Go type `time.Duration` as explained in https://github.com/kubernetes/apimachinery/issues/131, and b) a lack of validation within Flux to restrict allowed values.",
+  "details": "Flux controllers are vulnerable to a denial of service attack.\n\nUsers that have permissions to change Flux's objects, either through a Flux source or directly within a cluster, can provide invalid data to fields .spec.interval or .spec.timeout (and structured variations of these fields), causing the entire object type to stop being processed.\n\nThe issue has two root causes: a) the Kubernetes type metav1.Duration is not fully compatible with the Go type time.Duration as explained in https://github.com/kubernetes/apimachinery/issues/131, and b) a lack of validation within Flux to restrict allowed values.",
   "affected": [
     {
       "package": {

data/osv/GO-2022-1083.json

@@ -8,7 +8,7 @@
     "GHSA-59hj-62f5-fgmc"
   ],
   "summary": "Panic on malformed messages in github.com/free5gc/aper",
-  "details": "A malformed message can crash the free5gc/amf and free5gc/ngap decoders via an index-out-of-range panic in `aper.GetBitString`.",
+  "details": "A malformed message can crash the free5gc/amf and free5gc/ngap decoders via an index-out-of-range panic in aper.GetBitString.",
   "affected": [
     {
       "package": {

data/osv/GO-2022-1175.json

@@ -8,7 +8,7 @@
     "GHSA-cq2g-pw6q-hf7j"
   ],
   "summary": "Exposure of local files in github.com/cortexproject/cortex",
-  "details": "A malicious actor could remotely read local files by submitting to the Alertmanager Set Configuration API maliciously crafted inputs. Only users of the Alertmanager service where `-experimental.alertmanager.enable-api` or `enable_api: true` is configured are affected.",
+  "details": "A malicious actor could remotely read local files by submitting to the Alertmanager Set Configuration API maliciously crafted inputs. Only users of the Alertmanager service where \"-experimental.alertmanager.enable-api\" or \"enable_api: true\" is configured are affected.",
   "affected": [
     {
       "package": {

data/osv/GO-2022-1180.json

@@ -8,7 +8,7 @@
     "GHSA-m3cq-xcx9-3gvm"
   ],
   "summary": "Verification rule bypass in github.com/kyverno/kyverno",
-  "details": "`verifyImages` rules can be bypassed by a malicious proxy/registry.",
+  "details": "A malicious proxy/registry can bypass verifyImages rules.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1547.json

@@ -8,7 +8,7 @@
     "GHSA-pwcw-6f5g-gxf8"
   ],
   "summary": "Information disclosure in helm.sh/helm/v3",
-  "details": "An information disclosure vulnerability exists in the `getHostByName` template function.\n\n`getHostByName` is a Helm template function introduced in Helm v3. The function is able to accept a hostname and return an IP address for that hostname. To get the IP address the function performs a DNS lookup. The DNS lookup happens when used with `helm install|upgrade|template` or when the Helm SDK is used to render a chart.\n\nInformation passed into the chart can be disclosed to the DNS servers used to lookup the IP address. For example, a malicious chart could inject `getHostByName` into a chart in order to disclose values to a malicious DNS server.",
+  "details": "An information disclosure vulnerability exists in the getHostByName template function.\n\nThe function getHostByName is a Helm template function introduced in Helm v3. The function is able to accept a hostname and return an IP address for that hostname. To get the IP address the function performs a DNS lookup. The DNS lookup happens when used with \"helm install|upgrade|template\" or when the Helm SDK is used to render a chart.\n\nInformation passed into the chart can be disclosed to the DNS servers used to lookup the IP address. For example, a malicious chart could inject getHostByName into a chart in order to disclose values to a malicious DNS server.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1548.json

@@ -8,7 +8,7 @@
     "GHSA-mv6w-j4xc-qpfw"
   ],
   "summary": "Repository access credential leak in github.com/argoproj/argo-cd/v2",
-  "details": "Argo CD has an output sanitization bug which leaks repository access credentials in error messages.\n\nThese error messages are visible to the user, and they are logged. The error message is visible when a user attempts to create or update an Application via the Argo CD API (and therefor the UI or CLI).\n\nThe user must have `applications, create` or `applications, update` RBAC access to reach the code which may produce the error. The user is not guaranteed to be able to trigger the error message. They may attempt to spam the API with requests to trigger a rate limit error from the upstream repository.\n\nIf the user has `repositories, update` access, they may edit an existing repository to introduce a URL typo or otherwise force an error message.",
+  "details": "Argo CD has an output sanitization bug which leaks repository access credentials in error messages.\n\nThese error messages are visible to the user, and they are logged. The error message is visible when a user attempts to create or update an Application via the Argo CD API (and therefor the UI or CLI).\n\nThe user must have \"applications, create\" or \"applications, update\" RBAC access to reach the code which may produce the error. The user is not guaranteed to be able to trigger the error message. They may attempt to spam the API with requests to trigger a rate limit error from the upstream repository.\n\nIf the user has \"repositories, update\" access, they may edit an existing repository to introduce a URL typo or otherwise force an error message.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1557.json

@@ -8,7 +8,7 @@
     "GHSA-q264-w97q-q778"
   ],
   "summary": "Denial of service via HAMT decoding panic in github.com/ipfs/go-unixfs",
-  "details": "Trying to read malformed HAMT sharded directories can cause panics and virtual memory leaks. If you are reading untrusted user input, an attacker can then trigger a panic.\n\nThis is caused by bogus `fanout` parameter in the HAMT directory nodes. A workaround is to not feed untrusted user data to the decoding functions.",
+  "details": "Trying to read malformed HAMT sharded directories can cause panics and virtual memory leaks. If you are reading untrusted user input, an attacker can then trigger a panic.\n\nThis is caused by bogus \"fanout\" parameter in the HAMT directory nodes. A workaround is to not feed untrusted user data to the decoding functions.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1558.json

@@ -8,7 +8,7 @@
     "GHSA-2h6c-j3gf-xp9r"
   ],
   "summary": "Denial of service via malformed size parameters in github.com/ipfs/go-bitfield",
-  "details": "When feeding untrusted user input into the size parameter of `NewBitfield` and FromBytes functions, an attacker can trigger panics.\n\nThis happens when the size is a not a multiple of 8 or is negative.\n\nA workaround is to ensure size%8 == 0 \u0026\u0026 size \u003e= 0 yourself before calling NewBitfield or FromBytes.",
+  "details": "When feeding untrusted user input into the size parameter of NewBitfield and FromBytes functions, an attacker can trigger panics.\n\nThis happens when the size is a not a multiple of 8 or is negative.\n\nA workaround is to ensure size%8 == 0 \u0026\u0026 size \u003e= 0 yourself before calling NewBitfield or FromBytes.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1566.json

@@ -8,7 +8,7 @@
     "GHSA-9w8x-5hv5-r6gw"
   ],
   "summary": "Cross site scripting in github.com/usememos/memos",
-  "details": "A malicious actor can introduce links starting with a `javascript:` scheme due to insufficient checks on external resources. This can be used as a part of Cross-site Scripting (XSS) attack.",
+  "details": "A malicious actor can introduce links starting with a \"javascript:\" scheme due to insufficient checks on external resources. This can be used as a part of Cross-site Scripting (XSS) attack.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1602.json

@@ -8,7 +8,7 @@
     "GHSA-6gc3-crp7-25w5"
   ],
   "summary": "Denial of service via deflate decompression bomb in github.com/russellhaering/gosaml2",
-  "details": "A bug in SAML authentication library can result in Denial of Service attacks.\n\nAttackers can craft a `deflate`-compressed request which will consume significantly more memory during processing than the size of the original request. This may eventually lead to memory exhaustion and the process being killed.",
+  "details": "A bug in SAML authentication library can result in Denial of Service attacks.\n\nAttackers can craft a \"deflate\"-compressed request which will consume significantly more memory during processing than the size of the original request. This may eventually lead to memory exhaustion and the process being killed.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1713.json

@@ -8,7 +8,7 @@
     "GHSA-xq3x-grrj-fj6x"
   ],
   "summary": "Path traversal in github.com/sjqzhang/go-fastdfs",
-  "details": "An attacker can craft a remote request to upload a file to `/group1/upload` that uses path traversal to instead write the file contents to an attacker controlled path on the server.",
+  "details": "An attacker can craft a remote request to upload a file to \"/group1/upload\" that uses path traversal to instead write the file contents to an attacker controlled path on the server.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1717.json

@@ -8,7 +8,7 @@
     "GHSA-735r-hv67-g38f"
   ],
   "summary": "Improper handling of keyspaces in vitess.io/vitess",
-  "details": "Users can create a keyspace containing `/`. Future attempts to view keyspaces from some tools (including VTAdmin and `vtctldclient GetKeyspaces`) receive an error.",
+  "details": "Users can create a keyspace containing '/'. Future attempts to view keyspaces from some tools (including VTAdmin and \"vtctldclient GetKeyspaces\") receive an error.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-1881.json

@@ -7,7 +7,7 @@
     "GHSA-w5w5-2882-47pc"
   ],
   "summary": "The x/crisis package does not charge ConstantFee in github.com/cosmos/cosmos-sdk",
-  "details": "If a transaction is sent to the `x/crisis` module to check an invariant, the ConstantFee parameter of the chain is not charged.\n\nNo patch will be released, as the package is planned to be deprecated and replaced.",
+  "details": "If a transaction is sent to the x/crisis module to check an invariant, the ConstantFee parameter of the chain is not charged.\n\nNo patch will be released, as the package is planned to be deprecated and replaced.",
   "affected": [
     {
       "package": {

data/osv/GO-2023-2133.json

@@ -8,7 +8,7 @@
     "GHSA-fr2g-9hjm-wr23"
   ],
   "summary": "Authorization bypass in github.com/nats-io/nats-server/v2",
-  "details": "Without any authorization rules in the nats-server, users can connect without authentication.\n\nBefore nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an \"authorization\" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, \"$G\". Users inside accounts go into the newer \"accounts\" block.\n\nIf an \"accounts\" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. When the only account added is the system account \"$SYS\", the nats-server would create an implicit user in \"$G\" and set it as the `no_auth_user` account, enabling the same \"without authentication\" logic as without any rules.\n\nThis preserved the ability to connect simply, and then add one authenticated login for system access.\n\nBut with an \"authorization\" block, this is wrong. Users exist in the global account, with login rules. And in simple testing, they might still connect fine without administrators seeing that authentication has been disabled.\n\nIn the fixed versions, using an \"authorization\" block will inhibit the implicit creation of a \"$G\" user and setting it as the `no_auth_user` target. In unfixed versions, just creating a second account, with no users, will also inhibit this behavior.",
+  "details": "Without any authorization rules in the nats-server, users can connect without authentication.\n\nBefore nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an \"authorization\" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, \"$G\". Users inside accounts go into the newer \"accounts\" block.\n\nIf an \"accounts\" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. When the only account added is the system account \"$SYS\", the nats-server would create an implicit user in \"$G\" and set it as the \"no_auth_user\" account, enabling the same \"without authentication\" logic as without any rules.\n\nThis preserved the ability to connect simply, and then add one authenticated login for system access.\n\nBut with an \"authorization\" block, this is wrong. Users exist in the global account, with login rules. And in simple testing, they might still connect fine without administrators seeing that authentication has been disabled.\n\nIn the fixed versions, using an \"authorization\" block will inhibit the implicit creation of a \"$G\" user and setting it as the \"no_auth_user\" target. In unfixed versions, just creating a second account, with no users, will also inhibit this behavior.",
   "affected": [
     {
       "package": {