8000 Merge pull request #718 from github/removing-lgtm-references · github/securitylab@9335e32 · GitHub
[go: up one dir, main page]

Skip to content

Commit 9335e32

Browse files
authored
Merge pull request #718 from github/removing-lgtm-references
Replaces databases, blog URLs and removes lgtm
2 parents cbc3e4d + a29b9b8 commit 9335e32

File tree

24 files changed

+64
-53
lines changed

24 files changed

+64
-53
lines changed
Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1 @@
1-
Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/microsoft/chakracore/ChakraCore-revision-2017-April-12--18-13-26.zip)
2-
3-
We now also have this query in our default suite: https://lgtm.com/rules/2156560627/
1+
Use [this snapshot](https://github.com/github/securitylab/releases/download/chakracore-codeql-database/ChakraCore-revision-2017-April-12--18-13-26.zip)
Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
# Facebook Fizz integer overflow vulnerability (CVE-2019-3560)
22

3-
Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/facebook/fizz/facebookincubator_fizz_cpp-srcVersion_c69ad1baf3f04620393ebadc3eedd130b74f4023-dist_odasa-lgtm-2019-01-13-f9dca2a-universal.zip) for the demo.
3+
Use [this snapshot](https://github.com/github/securitylab/releases/download/facebook-codeql-database/facebookincubator_fizz_cpp-srcVersion_c69ad1baf3f04620393ebadc3eedd130b74f4023-dist_odasa-lgtm-2019-01-13-f9dca2a-universal.zip) for the demo.
44

55
[Fizz](https://github.com/facebookincubator/fizz) contained a remotely triggerable infinite loop. For more details about the bug, see this [blog post](https://securitylab.github.com/research/facebook-fizz-CVE-2019-3560). A proof-of-concept exploit is available [here](https://github.com/github/securitylab/tree/95c0bcc670f3b3d98a4d578f8993f8138092b94f/SecurityExploits/Facebook/Fizz/CVE-2019-3560).
Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
1-
[Blog post](https://lgtm.com/blog/qualcomm_copy_from_user)
1+
[Blog post](https://securitylab.github.com/research/stack-buffer-overflow-qualcomm-msm/)
22

3-
[Snapshot for this demo](https://downloads.lgtm.com/snapshots/cpp/qualcomm/msm/msm-4.4-revision-2017-May-07--08-33-56.zip)
3+
[Snapshot for this demo](https://github.com/github/securitylab/releases/download/qualcomm-msm-codeql-database/msm-4.4-revision-2017-May-07--08-33-56.zip)
44

55
The blog post was written before we had the C++ dataflow library, so these demo queries are a bit different than the blog post.
Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
1-
[Blog post](https://lgtm.com/blog/apple_xnu_dtrace_CVE-2017-13782)
1+
[Blog post](https://securitylab.github.com/research/apple-xnu-dtrace-CVE-2017-13782/)
22

33
Bug was fixed in [macOS High Sierra 10.13.1](https://support.apple.com/en-us/HT208221).
44

5-
[This snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13) has the bug.
5+
[This snapshot](https://github.com/github/securitylab/releases/download/xnu-codeql-database/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13) has the bug.
Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
1-
[Blog post](https://lgtm.com/blog/apple_xnu_nfs_boot_CVE-2018-4136_CVE-2018-4160)
1+
[Blog post](https://securitylab.github.com/research/apple-xnu-nfs-boot/)
22

33
Bug was fixed in [macOS High Sierra 10.13.4](https://support.apple.com/en-gb/HT208692).
44

5-
[This snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip) has the bug.
5+
[This snapshot](https://github.com/github/securitylab/releases/download/xnu-macos10.13.3-codeql-database/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip) has the bug.

CodeQL_Queries/cpp/XNU_icmp_error_CVE-2018-4407/00_mbuf_copydata_tainted_size.ql

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010
/*
1111
* This query is explained in detail in this blog post:
1212
*
13-
* https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407
13+
* https://securitylab.github.com/research/apple-xnu-icmp-error-CVE-2018-4407/
1414
*
1515
* It is based on the assumption that the function `m_mtod`, which returns
1616
* a pointer to the data stored in an `mbuf`, often returns a buffer
Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
# Apple XNU icmp_error CVE-2018-4407
22

3-
Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/xnu-4570.71.2_macOS-10.13.6_Semmle-1.18.0.zip) for the demo.
3+
Use [this snapshot](https://github.com/github/securitylab/releases/download/xnu-macos10.13.6-codeql-database/xnu-4570.71.2_macOS-10.13.6_Semmle-1.18.0.zip) for the demo.
44

5-
There are two parts to this demo. The first part is `00_mbuf_copydata_tainted_size.ql`, which is the dataflow query that found the bug. It is explained in detail in [this blog post](https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407). The problem with this query is that it does not find the true source of the untrusted data. This is because it assumes that any call to the function named `m_mtod` can return untrusted data. But not every `mbuf` contains untrusted data. So the second part of the demo, corresponding to [this blog post](https://lgtm.com/blog/apple_xnu_icmp_nfs_pocs), is to use dataflow analysis to find a path that gets an untrusted `mbuf` into `icmp_error`. The second part of the demo is developed in steps, starting with `01_paths_to_icmp_error.ql`.
5+
There are two parts to this demo. The first part is `00_mbuf_copydata_tainted_size.ql`, which is the dataflow query that found the bug. It is explained in detail in [this blog post](https://securitylab.github.com/research/apple-xnu-icmp-error-CVE-2018-4407/). The problem with this query is that it does not find the true source of the untrusted data. This is because it assumes that any call to the function named `m_mtod` can return untrusted data. But not every `mbuf` contains untrusted data. So the second part of the demo, corresponding to [this blog post](https://securitylab.github.com/research/apple-xnu-exploit-icmp-poc/), is to use dataflow analysis to find a path that gets an untrusted `mbuf` into `icmp_error`. The second part of the demo is developed in steps, starting with `01_paths_to_icmp_error.ql`.
Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
https://lgtm.com/blog/apple_xnu_packet_mangler_CVE-2017-13904
1+
https://securitylab.github.com/research/CVE-2018-4249-apple-xnu-packet-mangler/
22

33
There were multiple bugs in `packet_mangler.c`. One of the infinite loop bugs was fixed in macOS High Sierra 10.13.2. The other bugs were fixed in macOS High Sierra 10.13.5.
44

@@ -8,6 +8,6 @@ For a demo, the best query to show is `tcphdr_mbuf_copydata.ql`, because it show
88

99
`InfiniteLoop.ql` is a query inspired by one of the bugs in this code: the loop might not terminate because the loop counter is updated with a compound assignment (`+=`). We wrote an exploit which causes the right hand side of the assignment to be zero, which means that the loop runs forever.
1010

11-
All three queries find results in [this snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13).
11+
All three queries find results in [this snapshot](https://github.com/github/securitylab/releases/download/xnu-macos10.13-codeql-database/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13).
1212

13-
The queries also find results in [this newer snapshot for 10.13.3](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip). Apple thought they had fixed the infinite loop bug in 10.13.2, by changing the loop condition to a `>`. They were wrong.
13+
The queries also find results in [this newer snapshot for 10.13.3](https://github.com/github/securitylab/releases/download/xnu-macos10.13.3-codeql-database/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip). Apple thought they had fixed the infinite loop bug in 10.13.2, by changing the loop condition to a `>`. They were wrong.

CodeQL_Queries/cpp/libjpeg-turbo-oob/README.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ This is demo is an example of variant analysis on a recent [bugfix](https://gith
22

33
The fix prevents an out-of-bounds access when processing malformed BMP files: when reading a BMP file, the library allocates a colour map based on the number of colours declared in the BMP header. Later on, individual bytes are read from the file and used as indices into this colour map. Previously, this was done without checking whether the byte actually represented a valid colour, which could cause an out-of-bounds access. The fix introduces a field in the same struct as the colour map that records its size, and checks the index against it, aborting with an error if the index is out of range.
44

5-
A snapshot of libjpeg-turbo from before the fix is [here](https://downloads.lgtm.com/snapshots/cpp/libjpeg-turbo/libjpeg-turbo-revision-0fa7850aeb273204acd57be11f328b2be5d97dc6.zip), and one that contains the fix is [here](https://downloads.lgtm.com/snapshots/cpp/libjpeg-turbo/libjpeg-turbo-revision-d5f281b734425fc1d930ff2c3f8441aad731343e.zip).
5+
A snapshot of libjpeg-turbo from before the fix is [here](https://github.com/github/securitylab/releases/download/lipjpeg-turbo-codeql-database/libjpeg-turbo-revision-0fa7850aeb273204acd57be11f328b2be5d97dc6.zip), and one that contains the fix is [here](https://github.com/github/securitylab/releases/download/lipjpeg-turbo-codeql-database-patched/libjpeg-turbo-revision-d5f281b734425fc1d930ff2c3f8441aad731343e.zip).
66

77
The first five QL files develop a query that flags exactly the fixed accesses on the former snapshot, and nothing on the latter; the last query is a generalisation that finds a new instance of the same problem. All queries are run on the fixed snapshot, except when stated otherwise.
88

@@ -11,6 +11,6 @@ The first five QL files develop a query that flags exactly the fixed accesses on
1111
- 02b_find_guarded_colormap_index_working.ql: The previous query doesn't actually work, since `ERREXIT` isn't recognised as being a non-returning macro. This query fixes that.
1212
- 03_find_unguarded_colormap_index.ql: Flipping the logic around, we now look for _unguarded_ indexing. This gives a few false positives in cases where `cmap_length` isn't used. There is still a guard in these cases, but it's against a parameter that happens to contain the size of the colour map.
1313
- 04_find_unguarded_colormap_no_fps.ql: Add inter-procedural tracking to reason about the flow of colour maps and their sizes. This eliminates the remaining FPs on the fixed snapshot, and gives the expected results on the original snapshot.
14-
- 05_find_unguarded_colormap_generalised.ql: By removing the hardcoded references to `_bmp_source_struct`, we get a more general query that looks for other unguarded indexes into colour maps. This gives yet more false positives, since there are a few other guarding patterns, but the first three results are actually true positives, which we [reported](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/295). A snapshot with these results fixed is available [here](https://downloads.lgtm.com/snapshots/cpp/libjpeg-turbo/libjpeg-turbo-revision-d00d7d8c194e587ed10a395e0f307ce9dddf5687.zip).
14+
- 05_find_unguarded_colormap_generalised.ql: By removing the hardcoded references to `_bmp_source_struct`, we get a more general query that looks for other unguarded indexes into colour maps. This gives yet more false positives, since there are a few other guarding patterns, but the first three results are actually true positives, which we [reported](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/295). A snapshot with these results fixed is available [here](https://github.com/github/securitylab/releases/download/lipjpeg-turbo-codeql-database-patched/libjpeg-turbo-revision-d00d7d8c194e587ed10a395e0f307ce9dddf5687.zip).
1515

1616
Note that the final query is somewhat non-trivial (>100 LoC, uses global value numbering, guards and inter-procedural flow), so it's perhaps best used with an audience that has seen some simple QL before.
Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
# Eating error codes in libssh2
22

3-
Download this [snapshot](https://downloads.lgtm.com/snapshots/cpp/libssh2/libssh2_libssh2_C_C++_38bf7ce.zip) for the demo.
3+
Download this [snapshot](https://github.com/github/securitylab/releases/download/libssh2-codeql-database/libssh2_libssh2_C_C++_38bf7ce.zip) for the demo.
44

55
This demo shows how to develop, step-by-step, the query from the [blog post](https://blog.semmle.com/libssh2-integer-overflow/) about libssh2 CVE-2019-13115. This query did not find the bug that caused the CVE. It is instead about doing variant analysis on a bug that we noticed on the development branch of libssh2. We sent the query results to the libssh2 development team and they were able to fix all the variants before the next version of libssh2 was released.
66

7-
[This](https://lgtm.com/projects/g/libssh2/libssh2/snapshot/6e2f5563c80521b3cde72a6fcdb675c2e085f9cf/files/src/hostkey.c?sort=name&dir=ASC&mode=heatmap&__hstc=70225743.5fa8704c8874c6eafaef219923a26734.1534954774206.1564532078978.1564925733575.72&__hssc=70225743.2.1565139962633&__hsfp=997709570#L677) is an example of the bug. The problem is that `_libssh2_get_c_string` returns a negative integer as an error code, but the type of `r_len` is `unsigned int`, so the error code is accidentally ignored.
7+
The problem is that `_libssh2_get_c_string` returns a negative integer as an error code, but the type of `r_len` is `unsigned int`, so the error code is accidentally ignored.
88

99
For a shorter demo, stop at step 02. Steps 03 and 04 make the query more sophisticated by adding local data flow and range analysis.

0 commit comments

Comments
 (0)
0