dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-01-13T11:08:57Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/199Verify that random calls are seeded and used appropriately2022-01-13T11:08:57ZPeter DaviesVerify that random calls are seeded and used appropriatelyVerify that random calls are seeded and used appropriately
The Google Compute Platform randomization attack is a good reminder that we should examine PRNG use dhcp server and relay to ensure that we are using (pseudo-)randomness appro...Verify that random calls are seeded and used appropriately
The Google Compute Platform randomization attack is a good reminder that we should examine PRNG use dhcp server and relay to ensure that we are using (pseudo-)randomness appropriately.
Please treat this ticket as:
a reminder to review PRNG use in your project to ensure that it is used properly
a request to report on the status of that review, so that users who search for this ticket can satisfy themselves that we have checked our usage and believe it to be reasonable
The Google Compute Platform randomization attack in dhclient publicly available here: [https://github.com/irsl/gcp-dhcp-takeover-code-exec.](https://github.com/irsl/gcp-dhcp-takeover-code-exec).
also: [https://gitlab.isc.org/isc-projects/dhcp/-/issues/197](https://gitlab.isc.org/isc-projects/dhcp/-/issues/197)https://gitlab.isc.org/isc-projects/dhcp/-/issues/251Potential UAF in ISC DHCP (with RCE opportunity)2022-07-18T18:04:52ZCathy AlmondPotential UAF in ISC DHCP (with RCE opportunity)As submitted (encrypted) to Security Officer :
```
Hi,
I'm a security researcher. I found a potential UAF exist in ISC DHCP project.
Details:
In function store_options:
```
oc = lookup_option (u, cfg_options, code);
......
...As submitted (encrypted) to Security Officer :
```
Hi,
I'm a security researcher. I found a potential UAF exist in ISC DHCP project.
Details:
In function store_options:
```
oc = lookup_option (u, cfg_options, code);
......
struct buffer *bp = (struct buffer *)0;
if (!buffer_allocate (&bp, length, MDL)) {
option_cache_dereference (&oc, MDL);
data_string_forget (&od, MDL);
data_string_forget (&encapsulation, MDL);
continue;
}
```
variable oc is get from function lookup_option, but this function won't make a reference of oc. However, if buffer_allocate failed in some contidition, it will try to derefer to oc. If oc only has one reference or we can trigger it several times, this will let oc be freed but some objects still have its reference.
Impact:
this may be trigger by a client which can access 68 port of target host to gain a RCE.
```
No proof of concept that this can actually be used to trigger RCE, so currently this is a theoretical vulnerability only.https://gitlab.isc.org/isc-projects/dhcp/-/issues/252A potential null reference in dhcp project2022-07-22T12:34:42ZPeter DaviesA potential null reference in dhcp projectThe following was received on Thursday 14th July 2022 by Security Officer from Victor Tom <vv474172261@gmail.com>
Hi,
in function parse_executable_statements:
```c
int parse_executable_statements (statements, cfile, lose, case_context)...The following was received on Thursday 14th July 2022 by Security Officer from Victor Tom <vv474172261@gmail.com>
Hi,
in function parse_executable_statements:
```c
int parse_executable_statements (statements, cfile, lose, case_context)...
{
next = statements;
while (parse_executable_statement (next, cfile, lose, case_context))
next = &((*next) -> next);
...
}
```
it assumes `parse_executable_statement` will return 1 with setting statements.
However, in function parse_executable_statement:
```c
switch(token){
case EVAL:
skip_token(&val, (unsigned *)0, cfile);
if (!executable_statement_allocate (result, MDL))
log_fatal ("no memory for eval statement.");
(*result) -> op = eval_statement;
if (!parse_expression (&(*result) -> data.eval,
cfile, lose, context_data, /* XXX */
(struct expression **)0, expr_none)) {
if (!*lose)
parse_warn (cfile,
"expecting data expression.");
else
*lose = 1;
skip_to_semi (cfile);
executable_statement_dereference (result, MDL);
return 0;
}
if (!parse_semi (cfile)) { <<<<<<<<<L0
*lose = 1;
executable_statement_dereference (result, MDL); <<<<<<<<<<L1
}
break;
}
return 1;
```
if case is EVAL, and parse_semi(cfile) returns 0 at Lable L0, it will derefer result and free result and set it to 0.
This is unexcepted by parse_executable_statements. Thus, it may refer to a NULL pointer.
I don't have a poc, but this situation is expected if we can control cfile's content.
Regards,
VictorV of Cyber Kunlun Labhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/278isc dhcp missing check the length of server identifier2023-04-05T14:50:12ZPeter Daviesisc dhcp missing check the length of server identifier
Date: 21/03/2023, 08.50
Hello, I have find a bug in isc-dhcp 4.4.3. The length of server identifier option is 4 bytes. While, I find in dhcprequest() it dose not check the length of it before memecpy the data.
```
oc = l...
Date: 21/03/2023, 08.50
Hello, I have find a bug in isc-dhcp 4.4.3. The length of server identifier option is 4 bytes. While, I find in dhcprequest() it dose not check the length of it before memecpy the data.
```
oc = lookup_option (&dhcp_universe, packet -> options, DHO_DHCP_SERVER_IDENTIFIER);
memset (&data, 0, sizeof data);
if (oc &&
evaluate_option_cache (&data, packet, (struct lease *)0,
(struct client_state *)0,
packet -> options, (struct option_state *)0,
&global_scope, oc, MDL)) {
sip.len = 4;
memcpy (sip.iabuf, data.data, 4);
```
Thus, I construct a packet with server identifier option 2 bytes("\x02AA"). And I find that it will overread and show the buffer info in the log, as show in the figure: (see email)
Also, I have found that there also has missing length check of the following options. But I can not tirgger them by poc, so I think these may be a bug.
- options 50 dhcprequest() dhcp.c line 472
- option 59 ack_lease() dhcp.c line3368
- option 58 ack_lease() dhcp.c line3385
- option 118 ack_lease() dhcp.c line3302