Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cli: version 2.6 generating different vulnerability hashes from 2.5 #680

Closed
matheusalcantarazup opened this issue Oct 15, 2021 · 1 comment · Fixed by #678
Closed

cli: version 2.6 generating different vulnerability hashes from 2.5 #680

matheusalcantarazup opened this issue Oct 15, 2021 · 1 comment · Fixed by #678
Labels
kind/bug Something isn't working

Comments

@matheusalcantarazup
Copy link
Contributor

What happened:
The vulnerability hashes from version 2.6.0 is different from 2.5.0. This causes new vulnerabilities to be reported. Vulnerabilities previously registered as false positive and accepted risk are reported again, but with a different hash.

What you expected to happen:
All vulnerability hashes are the same after update

How to reproduce it (as minimally and precisely as possible):
Create a example file with a leak:

package main

import  "fmt"

var password = "bla"

func main() {
        fmt.Println(password)
}

Execute horusec v2.5.0 results in this vulnerability:

$ horusecv2.5.0 start -p testdata -D

Language: Leaks
Severity: CRITICAL
Line: 10
Column: 1
SecurityTool: HorusecEngine
Confidence: MEDIUM
File: testdata/main.go
Code: password = "bla"
Details: Hard-coded password
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. For more information checkout the CWE-798 (https://cwe.mitre.org/data/definitions/798.html) advisory.
Type: Vulnerability
ReferenceHash: d0d384ba41837ca2ccdf68aadcb1ac91bcada34c6b403bd9824ca3624ea5768c

Execute horusec v2.6.0 results in this vulnerability:

$ horusecv2.6.0 start -p testdata -D

Language: Leaks
Severity: CRITICAL
Line: 10
Column: 1
SecurityTool: HorusecEngine
Confidence: MEDIUM
File: testdata/main.go
Code: password = "bla"
Details: HS-LEAKS-26: Hard-coded password
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. For more information checkout the CWE-798 (https://cwe.mitre.org/data/definitions/798.html) advisory.
Type: Vulnerability
ReferenceHash: 55e2ffceadb5dd08f812f395ab54fb4a70b6acd4516acd006d4ca3abf0016fd8

Note that the ReferenceHash from two versions is different. Was expected to be equals.

Anything else we need to know?:
Affected versions:

  • v2.6.0
  • v2.6.1
  • v2.6.2
@matheusalcantarazup matheusalcantarazup added the kind/bug Something isn't working label Oct 15, 2021
matheusalcantarazup added a commit to ZupIT/horusec-devkit that referenced this issue Oct 15, 2021
A new field VulnHashInvalid was added on vulnerability struct to allow
cli match the valid and invalid hashes of vulnerability. For more info
see ZupIT/horusec#680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup added a commit that referenced this issue Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the
Details of vulnerability is used to generate the vulnerability hash, so
adding the rule id on details generate a different hash which cause a
breaking change. So this commit remove the rule id prefix from Details
field of Vulnerability and also add a workaround to users that is
already using the new hash as a false positive and risk accept.
To support the two ways of hashing the vulnerability a new field was
added on Vulnerability struct that represents the breaking way, so we
generate the two hashes of vulnerability and when we set the
vulnerability to false positive/risk accept according to config file we
use the two hashes to match.

Fixes #680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup added a commit to ZupIT/horusec-devkit that referenced this issue Oct 15, 2021
A new field VulnHashInvalid was added on vulnerability struct to allow
cli match the valid and invalid hashes of vulnerability. For more info
see ZupIT/horusec#680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
wiliansilvazup pushed a commit to ZupIT/horusec-devkit that referenced this issue Oct 15, 2021
…113)

A new field VulnHashInvalid was added on vulnerability struct to allow
cli match the valid and invalid hashes of vulnerability. For more info
see ZupIT/horusec#680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup added a commit that referenced this issue Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the
Details of vulnerability is used to generate the vulnerability hash, so
adding the rule id on details generate a different hash which cause a
breaking change. So this commit remove the rule id prefix from Details
field of Vulnerability and also add a workaround to users that is
already using the new hash as a false positive and risk accept.
To support the two ways of hashing the vulnerability a new field was
added on Vulnerability struct that represents the breaking way, so we
generate the two hashes of vulnerability and when we set the
vulnerability to false positive/risk accept according to config file we
use the two hashes to match.

Fixes #680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup added a commit that referenced this issue Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the
Details of vulnerability is used to generate the vulnerability hash, so
adding the rule id on details generate a different hash which cause a
breaking change. So this commit remove the rule id prefix from Details
field of Vulnerability and also add a workaround to users that is
already using the new hash as a false positive and risk accept.
To support the two ways of hashing the vulnerability a new field was
added on Vulnerability struct that represents the breaking way, so we
generate the two hashes of vulnerability and when we set the
vulnerability to false positive/risk accept according to config file we
use the two hashes to match.

Fixes #680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup added a commit that referenced this issue Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the
Details of vulnerability is used to generate the vulnerability hash, so
adding the rule id on details generate a different hash which cause a
breaking change. So this commit remove the rule id prefix from Details
field of Vulnerability and also add a workaround to users that is
already using the new hash as a false positive and risk accept.
To support the two ways of hashing the vulnerability a new field was
added on Vulnerability struct that represents the breaking way, so we
generate the two hashes of vulnerability and when we set the
vulnerability to false positive/risk accept according to config file we
use the two hashes to match.

Fixes #680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
@wiliansilvazup wiliansilvazup linked a pull request Oct 15, 2021 that will close this issue
matheusalcantarazup added a commit that referenced this issue Oct 18, 2021
On pr #636 we add the rule id on description of vulnerability, but the
Details of vulnerability is used to generate the vulnerability hash, so
adding the rule id on details generate a different hash which cause a
breaking change. So this commit remove the rule id prefix from Details
field of Vulnerability and also add a workaround to users that is
already using the new hash as a false positive and risk accept.
To support the two ways of hashing the vulnerability a new field was
added on Vulnerability struct that represents the breaking way, so we
generate the two hashes of vulnerability and when we set the
vulnerability to false positive/risk accept according to config file we
use the two hashes to match.

Fixes #680

Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
@matheusalcantarazup
Copy link
Contributor Author

This issue was fixed on version v2.6.3. Users getting this problem please upgrade to this version or greater.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant