CVE-2018-12025 (GCVE-0-2018-12025)

Vulnerability from cvelistv5 – Published: 2018-06-11 10:00 – Updated: 2024-08-05 08:24
VLAI
Summary
The transferFrom function of a smart contract implementation for FuturXE (FXE), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equal to allowed value, the transfer session would stop execution by returning false. This makes no sense, because the transferFrom() function should require the transferring value to not exceed the allowed value in the first place. Suppose this function asks for the allowed value to be smaller than the input. Then, the attacker could easily ignore the allowance: after this condition, the `allowed[from][msg.sender] -= value;` would cause an underflow because the allowed part is smaller than the value. The attacker could transfer any amount of FuturXe tokens of any accounts to an appointed account (the `_to` address) because the allowed value is initialized to 0, and the attacker could bypass this restriction even without the victim's private key.
Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CWE
  • n/a
Assigner
References
Date Public
2018-06-11 00:00
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T08:24:03.670Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "n/a",
          "vendor": "n/a",
          "versions": [
            {
              "status": "affected",
              "version": "n/a"
            }
          ]
        }
      ],
      "datePublic": "2018-06-11T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "The transferFrom function of a smart contract implementation for FuturXE (FXE), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equal to allowed value, the transfer session would stop execution by returning false. This makes no sense, because the transferFrom() function should require the transferring value to not exceed the allowed value in the first place. Suppose this function asks for the allowed value to be smaller than the input. Then, the attacker could easily ignore the allowance: after this condition, the `allowed[from][msg.sender] -= value;` would cause an underflow because the allowed part is smaller than the value. The attacker could transfer any amount of FuturXe tokens of any accounts to an appointed account (the `_to` address) because the allowed value is initialized to 0, and the attacker could bypass this restriction even without the victim\u0027s private key."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "n/a",
              "lang": "en",
              "type": "text"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2018-06-11T09:57:01.000Z",
        "orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
        "shortName": "mitre"
      },
      "references": [
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "cve@mitre.org",
          "ID": "CVE-2018-12025",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "n/a",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "n/a"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "n/a"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "The transferFrom function of a smart contract implementation for FuturXE (FXE), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equal to allowed value, the transfer session would stop execution by returning false. This makes no sense, because the transferFrom() function should require the transferring value to not exceed the allowed value in the first place. Suppose this function asks for the allowed value to be smaller than the input. Then, the attacker could easily ignore the allowance: after this condition, the `allowed[from][msg.sender] -= value;` would cause an underflow because the allowed part is smaller than the value. The attacker could transfer any amount of FuturXe tokens of any accounts to an appointed account (the `_to` address) because the allowed value is initialized to 0, and the attacker could bypass this restriction even without the victim\u0027s private key."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "n/a"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff",
              "refsource": "MISC",
              "url": "https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
    "assignerShortName": "mitre",
    "cveId": "CVE-2018-12025",
    "datePublished": "2018-06-11T10:00:00.000Z",
    "dateReserved": "2018-06-07T00:00:00.000Z",
    "dateUpdated": "2024-08-05T08:24:03.670Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2018-12025",
      "date": "2026-07-17",
      "epss": "0.01606",
      "percentile": "0.73164"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:a:futurxe:futurxe:-:*:*:*:*:*:*:*\", \"matchCriteriaId\": \"08130AD0-57BB-4B83-80DE-F9B3C4F27397\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"The transferFrom function of a smart contract implementation for FuturXE (FXE), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equal to allowed value, the transfer session would stop execution by returning false. This makes no sense, because the transferFrom() function should require the transferring value to not exceed the allowed value in the first place. Suppose this function asks for the allowed value to be smaller than the input. Then, the attacker could easily ignore the allowance: after this condition, the `allowed[from][msg.sender] -= value;` would cause an underflow because the allowed part is smaller than the value. The attacker could transfer any amount of FuturXe tokens of any accounts to an appointed account (the `_to` address) because the allowed value is initialized to 0, and the attacker could bypass this restriction even without the victim\u0027s private key.\"}, {\"lang\": \"es\", \"value\": \"La funci\\u00f3n transferFrom de una implementaci\\u00f3n de contrato inteligente para FuturXE (FXE), un token Ethereum ERC20, permite a los atacantes realizar una transferencia no autorizada de activos digitales debido a un error l\\u00f3gico. El desarrollador se equivoc\\u00f3 con el juicio boleano - si el valor de entrada es menor o igual al valor permitido, la sesi\\u00f3n de transferencia detendr\\u00eda la ejecuci\\u00f3n devolviendo el valor \\\"false\\\". Esto no tiene sentido, porque la funci\\u00f3n transferFrom() deber\\u00eda requerir que el valor de transferencia no exceda el valor permitido en primer lugar. Supongamos que esta funci\\u00f3n pide que el valor permitido sea menor que la entrada. Entonces, el atacante podr\\u00eda ignorar f\\u00e1cilmente el permiso: despu\\u00e9s de esta condici\\u00f3n, el \\\"allowed[from][msg.sender] -= value;\\\" originar\\u00eda un flujo inferior porque la parte permitida es menor que el valor. El atacante podr\\u00eda transferir cualquier cantidad de tokens de FuturXe de cualquier cuenta a una cuenta designada (la direcci\\u00f3n \\\"_to\\\") porque el valor permitido se inicializa a 0 y el atacante podr\\u00eda omitir esta restricci\\u00f3n incluso sin la clave privada de la v\\u00edctima.\"}]",
      "id": "CVE-2018-12025",
      "lastModified": "2024-11-21T03:44:26.500",
      "metrics": "{\"cvssMetricV30\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.0\", \"vectorString\": \"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N\", \"baseScore\": 7.5, \"baseSeverity\": \"HIGH\", \"attackVector\": \"NETWORK\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"NONE\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"HIGH\", \"availabilityImpact\": \"NONE\"}, \"exploitabilityScore\": 3.9, \"impactScore\": 3.6}], \"cvssMetricV2\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"2.0\", \"vectorString\": \"AV:N/AC:L/Au:N/C:N/I:P/A:N\", \"baseScore\": 5.0, \"accessVector\": \"NETWORK\", \"accessComplexity\": \"LOW\", \"authentication\": \"NONE\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"PARTIAL\", \"availabilityImpact\": \"NONE\"}, \"baseSeverity\": \"MEDIUM\", \"exploitabilityScore\": 10.0, \"impactScore\": 2.9, \"acInsufInfo\": false, \"obtainAllPrivilege\": false, \"obtainUserPrivilege\": false, \"obtainOtherPrivilege\": false, \"userInteractionRequired\": false}]}",
      "published": "2018-06-11T10:29:00.297",
      "references": "[{\"url\": \"https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff\", \"source\": \"cve@mitre.org\", \"tags\": [\"Third Party Advisory\"]}, {\"url\": \"https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Third Party Advisory\"]}]",
      "sourceIdentifier": "cve@mitre.org",
      "vulnStatus": "Modified",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-20\"}, {\"lang\": \"en\", \"value\": \"CWE-191\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2018-12025\",\"sourceIdentifier\":\"cve@mitre.org\",\"published\":\"2018-06-11T10:29:00.297\",\"lastModified\":\"2024-11-21T03:44:26.500\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"The transferFrom function of a smart contract implementation for FuturXE (FXE), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equal to allowed value, the transfer session would stop execution by returning false. This makes no sense, because the transferFrom() function should require the transferring value to not exceed the allowed value in the first place. Suppose this function asks for the allowed value to be smaller than the input. Then, the attacker could easily ignore the allowance: after this condition, the `allowed[from][msg.sender] -= value;` would cause an underflow because the allowed part is smaller than the value. The attacker could transfer any amount of FuturXe tokens of any accounts to an appointed account (the `_to` address) because the allowed value is initialized to 0, and the attacker could bypass this restriction even without the victim\u0027s private key.\"},{\"lang\":\"es\",\"value\":\"La funci\u00f3n transferFrom de una implementaci\u00f3n de contrato inteligente para FuturXE (FXE), un token Ethereum ERC20, permite a los atacantes realizar una transferencia no autorizada de activos digitales debido a un error l\u00f3gico. El desarrollador se equivoc\u00f3 con el juicio boleano - si el valor de entrada es menor o igual al valor permitido, la sesi\u00f3n de transferencia detendr\u00eda la ejecuci\u00f3n devolviendo el valor \\\"false\\\". Esto no tiene sentido, porque la funci\u00f3n transferFrom() deber\u00eda requerir que el valor de transferencia no exceda el valor permitido en primer lugar. Supongamos que esta funci\u00f3n pide que el valor permitido sea menor que la entrada. Entonces, el atacante podr\u00eda ignorar f\u00e1cilmente el permiso: despu\u00e9s de esta condici\u00f3n, el \\\"allowed[from][msg.sender] -= value;\\\" originar\u00eda un flujo inferior porque la parte permitida es menor que el valor. El atacante podr\u00eda transferir cualquier cantidad de tokens de FuturXe de cualquier cuenta a una cuenta designada (la direcci\u00f3n \\\"_to\\\") porque el valor permitido se inicializa a 0 y el atacante podr\u00eda omitir esta restricci\u00f3n incluso sin la clave privada de la v\u00edctima.\"}],\"metrics\":{\"cvssMetricV30\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.0\",\"vectorString\":\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N\",\"baseScore\":7.5,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":3.9,\"impactScore\":3.6}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:N/AC:L/Au:N/C:N/I:P/A:N\",\"baseScore\":5.0,\"accessVector\":\"NETWORK\",\"accessComplexity\":\"LOW\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"PARTIAL\",\"availabilityImpact\":\"NONE\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":10.0,\"impactScore\":2.9,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":false}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-20\"},{\"lang\":\"en\",\"value\":\"CWE-191\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:futurxe:futurxe:-:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"08130AD0-57BB-4B83-80DE-F9B3C4F27397\"}]}]}],\"references\":[{\"url\":\"https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff\",\"source\":\"cve@mitre.org\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://medium.com/secbit-media/bugged-smart-contract-f-e-how-could-someone-mess-up-with-boolean-d2251defd6ff\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}"
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.