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

SystemSan: arbitrary DNS resolution detection #8448

Merged
merged 3 commits into from
Dec 1, 2022

Conversation

catenacyber
Copy link
Contributor

cc @oliverchang @jonathanmetzman

Here is a new bug class for SystemSan : arbitrary DNS resolution (like in log4j)

What do you think about it ?

@catenacyber
Copy link
Contributor Author

Rebased and fixed the conflict on #includes, and force-pushed

Friendly ping on this ?

cc @alan32liu

@oliverchang
Copy link
Collaborator

Rebased and fixed the conflict on #includes, and force-pushed

Friendly ping on this ?

cc @alan32liu

Thanks for this change. The idea is nice, and similar to what we had in mind, but the code style will need a bit of improvement to make this maintainable.

At a minimum we'd like to see the DNS parsing have proper structs/classes defined etc and in its own file. That said, are there any existing libraries out there we can also use for this instead of trying to roll our own?

@catenacyber
Copy link
Contributor Author

That said, are there any existing libraries out there we can also use for this instead of trying to roll our own?

Interesting point.
That depends on what you prefer : external dependencies or maintain your own code

The DNS parsing done here is specific to the case we are interested in (simple domain query)
And I thought you would not want any dependencies for SystemSan.
So, what do you prefer ?

@oliverchang
Copy link
Collaborator

That said, are there any existing libraries out there we can also use for this instead of trying to roll our own?

Interesting point. That depends on what you prefer : external dependencies or maintain your own code

The DNS parsing done here is specific to the case we are interested in (simple domain query) And I thought you would not want any dependencies for SystemSan. So, what do you prefer ?

That would depend on what the dependency looks like and its size :) e.g. If the dependency is a small header-only library that's well tested, that would be a good candidate.

Otherwise, we'd need to clean up this current implementation a bit before we can accept it.

@catenacyber
Copy link
Contributor Author

Here is a new version in its own file

I did not find any good candidate at first sight for a third party dns parsing library.
My best proposal would be https://docs.rs/dns-parser/latest/dns_parser/
Would rust suit you ?
The only dns parsing library I see on oss-fuzz is go-dns, which is in Golang... The other projects are full-fletched dns servers...

If we go for rolling our own, do I understand correctly the following ?
inspect_for_arbitrary_dns_pkt should create structures/classes such as a DNS Header (cf https://docs.rs/dns-parser/latest/dns_parser/struct.Header.html), and then check that the questions field of this structure is equal to 1 instead of directly doing if (uint8_t(data[4]) != 0 || uint8_t(data[5]) != 1) {

@catenacyber
Copy link
Contributor Author

Friendly ping on this ?

@catenacyber
Copy link
Contributor Author

@alan32liu what do you think about this ?

@DonggeLiu
Copy link
Contributor

DonggeLiu commented Oct 18, 2022

Would rust suit you ?

I could not think of any reasons against Rust or the candidate you proposed, but let's wait for @oliverchang in case I missed anything.

check that the questions field of this structure is equal to 1

IIUC, this questions field in the header represents the QDCOUNT (i.e., the number of entries in the question section), which I guess could be more than one in general?

@catenacyber
Copy link
Contributor Author

The reason against Rust is introducing a new language/toolchain for SystemSan (and the maintenance cost/complexity that comes with it)

IIUC, this questions field in the header represents the QDCOUNT (i.e., the number of entries in the question section), which I guess could be more than one in general?

Indeed, but I do not know where/when/how my software will issue such a request with multiple domains... Would you have an example ?

@catenacyber
Copy link
Contributor Author

ping @alan32liu what should be done for this PR ? Try it as is ? Or change something ?

@DonggeLiu
Copy link
Contributor

Let's try it as is, if @oliverchang does not have any other suggestions?

@oliverchang
Copy link
Collaborator

@jonathanmetzman can help merge and evaluate this. Sorry for the delay on this.

@oliverchang oliverchang merged commit 98eda2b into google:master Dec 1, 2022
oliverchang added a commit that referenced this pull request Dec 1, 2022
oliverchang added a commit that referenced this pull request Dec 1, 2022
Reverts #8448.

Build was broken in several places. 

Even once fixed, the `target_dns` example didn't work.
jonathanmetzman added a commit that referenced this pull request Dec 6, 2022
cc @oliverchang @alan32liu after #9100 and #8448

After compiling locally, I can see that
`./SystemSan ./target_dns -dict=vuln.dict`
crashes in a few seconds with
```
===BUG DETECTED: Arbitrary domain name resolution===
===Domain resolved: .f.z===
===DNS request type: 0, class: 256===
==315== ERROR: libFuzzer: deadly signal
    #0 0x539131 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3
    #1 0x457c48 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
    #2 0x43c923 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3
    #3 0x7fa57940041f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #4 0x7fa5793ff7db in send (/lib/x86_64-linux-gnu/libpthread.so.0+0x137db) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #5 0x503ba4 in __interceptor_send /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6802:17
    #6 0x7fa578abf462  (/lib/x86_64-linux-gnu/libresolv.so.2+0xb462) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    #7 0x7fa578abbc43 in __res_context_query (/lib/x86_64-linux-gnu/libresolv.so.2+0x7c43) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    #8 0x7fa578abc8ed in __res_context_search (/lib/x86_64-linux-gnu/libresolv.so.2+0x88ed) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    #9 0x7fa578ad2cc1  (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2cc1) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    #10 0x7fa578ad2e8b in _nss_dns_gethostbyname3_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2e8b) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    #11 0x7fa578ad2f41 in _nss_dns_gethostbyname2_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2f41) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    #12 0x7fa5792fdc9d in gethostbyname2_r (/lib/x86_64-linux-gnu/libc.so.6+0x130c9d) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #13 0x7fa5792d179e  (/lib/x86_64-linux-gnu/libc.so.6+0x10479e) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #14 0x7fa5792d2f58 in getaddrinfo (/lib/x86_64-linux-gnu/libc.so.6+0x105f58) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #15 0x4d93ac in getaddrinfo /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2667:13
    #16 0x56c8d9 in LLVMFuzzerTestOneInput /out/SystemSan/target_dns.cpp:35:11
    #17 0x43dec3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #18 0x43d6aa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    #19 0x43ed79 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    #20 0x43fa45 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
    #21 0x42edaf in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #22 0x458402 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #23 0x7fa5791f1082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #24 0x41f7ed in _start (/out/SystemSan/target_dns+0x41f7ed)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 2 CrossOver-ManualDict- DE: "f.z"-; base unit: ac3478d69a3c81fa62e60f5c3696165a4e5e6ac4
0x66,0x2e,0x7a,
f.z
artifact_prefix='./'; Test unit written to ./crash-926813b2d6adde373f96a10594a5314951588384
Base64: Zi56
```

You can also try
```
echo -n f.z > toto
./SystemSan ./target_dns toto  
```

Co-authored-by: Oliver Chang <oliverchang@users.noreply.github.com>
Co-authored-by: jonathanmetzman <31354670+jonathanmetzman@users.noreply.github.com>
eamonnmcmanus pushed a commit to eamonnmcmanus/oss-fuzz that referenced this pull request Mar 15, 2023
cc @oliverchang @jonathanmetzman 

Here is a new bug class for SystemSan : arbitrary DNS resolution (like
in log4j)

What do you think about it ?
eamonnmcmanus pushed a commit to eamonnmcmanus/oss-fuzz that referenced this pull request Mar 15, 2023
Reverts google#8448.

Build was broken in several places. 

Even once fixed, the `target_dns` example didn't work.
eamonnmcmanus pushed a commit to eamonnmcmanus/oss-fuzz that referenced this pull request Mar 15, 2023
cc @oliverchang @alan32liu after google#9100 and google#8448

After compiling locally, I can see that
`./SystemSan ./target_dns -dict=vuln.dict`
crashes in a few seconds with
```
===BUG DETECTED: Arbitrary domain name resolution===
===Domain resolved: .f.z===
===DNS request type: 0, class: 256===
==315== ERROR: libFuzzer: deadly signal
    #0 0x539131 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3
    google#1 0x457c48 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
    google#2 0x43c923 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3
    google#3 0x7fa57940041f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    google#4 0x7fa5793ff7db in send (/lib/x86_64-linux-gnu/libpthread.so.0+0x137db) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    google#5 0x503ba4 in __interceptor_send /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6802:17
    google#6 0x7fa578abf462  (/lib/x86_64-linux-gnu/libresolv.so.2+0xb462) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    google#7 0x7fa578abbc43 in __res_context_query (/lib/x86_64-linux-gnu/libresolv.so.2+0x7c43) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    google#8 0x7fa578abc8ed in __res_context_search (/lib/x86_64-linux-gnu/libresolv.so.2+0x88ed) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    google#9 0x7fa578ad2cc1  (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2cc1) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    google#10 0x7fa578ad2e8b in _nss_dns_gethostbyname3_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2e8b) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    google#11 0x7fa578ad2f41 in _nss_dns_gethostbyname2_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2f41) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    google#12 0x7fa5792fdc9d in gethostbyname2_r (/lib/x86_64-linux-gnu/libc.so.6+0x130c9d) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#13 0x7fa5792d179e  (/lib/x86_64-linux-gnu/libc.so.6+0x10479e) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#14 0x7fa5792d2f58 in getaddrinfo (/lib/x86_64-linux-gnu/libc.so.6+0x105f58) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#15 0x4d93ac in getaddrinfo /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2667:13
    google#16 0x56c8d9 in LLVMFuzzerTestOneInput /out/SystemSan/target_dns.cpp:35:11
    google#17 0x43dec3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    google#18 0x43d6aa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    google#19 0x43ed79 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    google#20 0x43fa45 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
    google#21 0x42edaf in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    google#22 0x458402 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    google#23 0x7fa5791f1082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#24 0x41f7ed in _start (/out/SystemSan/target_dns+0x41f7ed)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 2 CrossOver-ManualDict- DE: "f.z"-; base unit: ac3478d69a3c81fa62e60f5c3696165a4e5e6ac4
0x66,0x2e,0x7a,
f.z
artifact_prefix='./'; Test unit written to ./crash-926813b2d6adde373f96a10594a5314951588384
Base64: Zi56
```

You can also try
```
echo -n f.z > toto
./SystemSan ./target_dns toto  
```

Co-authored-by: Oliver Chang <oliverchang@users.noreply.github.com>
Co-authored-by: jonathanmetzman <31354670+jonathanmetzman@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants