This is an archived web site made available for research purposes. The web site is no longer maintained.

Challenge Information - NRFIN_00067

Commonly known as: Order_Up


Rounds Enabled

60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74

Details

Original Versions

Known Vulnerabilities

  • CWE-122 - Heap-based Buffer Overflow
  • CWE-131 - Incorrect Calculation of Buffer Size
  • CWE-704 - Incorrect Type Conversion or Cast
  • CWE-787 - Out-of-bounds Write
  • CWE-788 - Access of Memory Location After End of Buffer
  • CWE-805 - Buffer Access with Incorrect Length Value
  • CWEs are listed as indicated by the challenge author.

Deployed patches

Deployed IDS rules

None

Author Information

"Nick Davis" info@narfindustries.com

DARPA performer group

Narf Industries (NRFIN)

Description:

The hottest new thing in restaurants is to place your order at a fancy little computer at your table and have your food magically be delivered by robots.

To help assist future restaurants with their roll out of this technology, we've created Order Up. Order up can handle all of the table, customer, and order functionality that you need to run a restaurant. All you have to do is put a nifty computer at each table, one at the front entrance, and one in the kitchen.

Feature List:

Each table has a 3 course dinner. It starts with an appetizer, then the main course, then the dessert.

When a table either gets newly seated customers or the customers have finished their current course, they are presented with the menu to choose their next food items.

This CB Set is designed such that cb_1 represents the hostess and waitress and cb_2 - cb_10 are the tables. The client connects to cb_1 to issue commands. Then cb_1 will dispatch the hostess or waitress to the proper tables to handle each command. There are several standard commands that cb_1 will accept from a client, as listed here:

Add Customers - When new customers arrive at the restaurant, they are placed on a waiting list. As seats open up, they are seated.

Table Status - Check the status of each table in the restaurant.

Get Orders - Collect orders from all customers at every table that is ready to place another order.

Order Up - Deliver all orders to all customers at every table that has an order outstanding.

Bus Tables - At every table where the customers are finished eating, clear the table and reset it.

Each of cb_2 through cb_10 functions identically, except that they can have a different number of seats at each table, which is determined at run-time.

Vulnerability 1

In give_food_to_customer() in table.c:300ish cb_2, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 2

In give_food_to_customer() in table.c:300ish cb_3, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 3

In give_food_to_customer() in table.c:300ish cb_4, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 4

In give_food_to_customer() in table.c:300ish cb_5, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 5

In give_food_to_customer() in table.c:300ish cb_6, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 6

In give_food_to_customer() in table.c:300ish cb_7, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 7

In give_food_to_customer() in table.c:300ish cb_8, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 8

In give_food_to_customer() in table.c:300ish cb_9, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

Vulnerability 9

In give_food_to_customer() in table.c:300ish cb_10, there exists the ability for the client input to cause type confusion.

This function uses the ftype paramter provided by the client to determine the size of the food buffer. It then uses a different parameter, table.status, to determine which food buffer to write into. If the table.status does not match the o->ftype, then the wrong food will be written to the customer's food buffer associted with the current table.status. This is a problem, because the Meal food type is much larger than both the Appetizer or Dessert food types.

To exploit, send a Meal when the table.status is expecting a Dessert. This will cause the call to accept_food() to overwrite the Customer.fi ptr and the Customer.next ptr with the Meal.main data, it will also corrupt the heap data with the remainder of Meal.main, as well as Meal.veggies, Meal.side, and Meal.next (which is NULL) data.

Then when the food inspection function is called c->fi(), the fi pointer has been overwritten by client provided data and will cause TYPE 1 POV.

Since, the inspect_*() functions pass its parameters via registers, the Customer.id for the customer currently being fed resides in EDX.

There are a number of ways to patch this vulnerability. The easiest is to remove the ability for the buf location and bufsz to get out of sync, by removing the call to get_delivery_foodtype_from_table_status() at table.c:300. An equally simple solution is to move that function assignment to the top of the give_food_to_customer() function. Either change will result in the bufsz matching the size of buf and thus prevent POV.

Generic Class of Vulnerability

Heap Buffer Overflow Type Confusion

CWE Classification

CWE-122: Heap-Based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size CWE-704: Incorrect Type Conversion or Cast CWE-787: Out-of-bounds Write CWE-788: Access of Memory Location After End of Buffer CWE-805: Buffer Access with Incorrect Length Value

Challenges

  • The biggest challenge this CB was designed to test was how well a CRS can handle a CB Set with many CBs in it. The max number of CBs that are allowed in a CB Set is 10, so this CB has 10 CBs in it.
  • Next, this vulnerability exists in 9 of the 10 CBs. So, while each provided POV will only test one of them, they can still be POV'd if that one is patched, but the others 8 are not. Each POV 1-9 is targeted at cb_2 - cb_10 respectively.
  • Next, this CB Set will challenge a CRS to notice that multiple CBs are the same. This will determine if/how they can transition the patch from one CB to the others. As well as test if the CRS will patch each CB on their own, but in a different way.
  • The I/O between the poller/pov and cb_1 is not too difficult, which should allow for some successful exploration with fuzzers and solvers.
  • The improper buffer size length calculation can be fixed in a few ways that are not too difficult.

Difficulty

  • Discovering is easy
  • Proving is medium
  • Fixing is easy

POV Information

Round Source Destination Result POV Analysis Video
61 CSDS CodeJitsu Failed POV POV Watch
61 CSDS DeepRed Failed POV POV Watch
61 CSDS Disekt Failed POV POV Watch
61 CSDS ForAllSecure Failed POV POV Watch
61 CSDS Shellphish Failed POV POV Watch
61 CSDS TECHx Failed POV POV Watch
61 DeepRed CodeJitsu Failed POV POV Watch
61 DeepRed CSDS Failed POV POV Watch
61 DeepRed Disekt Failed POV POV Watch
61 DeepRed ForAllSecure Failed POV POV Watch
61 DeepRed Shellphish Failed POV POV Watch
61 DeepRed TECHx Failed POV POV Watch
62 CSDS CodeJitsu Failed POV POV Watch
62 CSDS DeepRed Failed POV POV Watch
62 CSDS Disekt Failed POV POV Watch
62 CSDS ForAllSecure Failed POV POV Watch
62 CSDS Shellphish Failed POV POV Watch
62 CSDS TECHx Failed POV POV Watch
62 DeepRed CodeJitsu Failed POV POV Watch
62 DeepRed CSDS Failed POV POV Watch
62 DeepRed Disekt Failed POV POV Watch
62 DeepRed ForAllSecure Failed POV POV Watch
62 DeepRed Shellphish Failed POV POV Watch
62 DeepRed TECHx Failed POV POV Watch
63 CodeJitsu Shellphish Failed POV through defenses POV Watch
63 CSDS CodeJitsu Failed POV POV Watch
63 CSDS DeepRed Failed POV POV Watch
63 CSDS Disekt Failed POV POV Watch
63 CSDS ForAllSecure Failed POV POV Watch
63 CSDS Shellphish Failed POV through defenses POV Watch
63 CSDS TECHx Failed POV POV Watch
63 DeepRed CodeJitsu Failed POV POV Watch
63 DeepRed CSDS Failed POV POV Watch
63 DeepRed Disekt Failed POV POV Watch
63 DeepRed ForAllSecure Failed POV POV Watch
63 DeepRed Shellphish Failed POV through defenses POV Watch
63 DeepRed TECHx Failed POV POV Watch
64 CodeJitsu Shellphish Failed POV through defenses POV Watch
64 CSDS CodeJitsu Failed POV POV Watch
64 CSDS DeepRed Failed POV POV Watch
64 CSDS Disekt Failed POV POV Watch
64 CSDS ForAllSecure Failed POV POV Watch
64 CSDS Shellphish Failed POV through defenses POV Watch
64 CSDS TECHx Failed POV POV Watch
64 DeepRed CodeJitsu Failed POV POV Watch
64 DeepRed CSDS Failed POV POV Watch
64 DeepRed Disekt Failed POV POV Watch
64 DeepRed ForAllSecure Failed POV POV Watch
64 DeepRed Shellphish Failed POV through defenses POV Watch
64 DeepRed TECHx Failed POV POV Watch
65 CSDS CodeJitsu Failed POV POV Watch
65 CSDS DeepRed Failed POV POV Watch
65 CSDS Disekt Failed POV POV Watch
65 CSDS ForAllSecure Failed POV POV Watch
65 CSDS Shellphish Failed POV through defenses POV Watch
65 CSDS TECHx Failed POV POV Watch
65 DeepRed CodeJitsu Failed POV POV Watch
65 DeepRed CSDS Failed POV POV Watch
65 DeepRed Disekt Failed POV POV Watch
65 DeepRed ForAllSecure Failed POV POV Watch
65 DeepRed Shellphish Failed POV through defenses POV Watch
65 DeepRed TECHx Failed POV POV Watch
66 CSDS CodeJitsu Failed POV POV Watch
66 CSDS DeepRed Failed POV POV Watch
66 CSDS Disekt Failed POV POV Watch
66 CSDS ForAllSecure Failed POV POV Watch
66 CSDS Shellphish Failed POV through defenses POV Watch
66 CSDS TECHx Failed POV POV Watch
66 DeepRed CodeJitsu Failed POV POV Watch
66 DeepRed CSDS Failed POV POV Watch
66 DeepRed Disekt Failed POV POV Watch
66 DeepRed ForAllSecure Failed POV POV Watch
66 DeepRed Shellphish Failed POV through defenses POV Watch
66 DeepRed TECHx Failed POV POV Watch
67 CSDS CodeJitsu Failed POV POV Watch
67 CSDS DeepRed Failed POV POV Watch
67 CSDS Disekt Failed POV POV Watch
67 CSDS ForAllSecure Failed POV POV Watch
67 CSDS Shellphish Failed POV through defenses POV Watch
67 CSDS TECHx Failed POV POV Watch
67 DeepRed CodeJitsu Failed POV POV Watch
67 DeepRed CSDS Failed POV POV Watch
67 DeepRed Disekt Failed POV POV Watch
67 DeepRed ForAllSecure Failed POV POV Watch
67 DeepRed Shellphish Failed POV through defenses POV Watch
67 DeepRed TECHx Failed POV POV Watch
68 CSDS CodeJitsu Failed POV POV Watch
68 CSDS DeepRed Failed POV POV Watch
68 CSDS Disekt Failed POV POV Watch
68 CSDS ForAllSecure Failed POV POV Watch
68 CSDS Shellphish Failed POV through defenses POV Watch
68 CSDS TECHx Failed POV POV Watch
68 DeepRed CodeJitsu Failed POV POV Watch
68 DeepRed CSDS Failed POV POV Watch
68 DeepRed Disekt Failed POV POV Watch
68 DeepRed ForAllSecure Failed POV POV Watch
68 DeepRed Shellphish Failed POV through defenses POV Watch
68 DeepRed TECHx Failed POV POV Watch
69 CSDS CodeJitsu Failed POV POV Watch
69 CSDS DeepRed Failed POV POV Watch
69 CSDS Disekt Failed POV POV Watch
69 CSDS ForAllSecure Failed POV POV Watch
69 CSDS Shellphish Failed POV through defenses POV Watch
69 CSDS TECHx Failed POV POV Watch
69 DeepRed CodeJitsu Failed POV POV Watch
69 DeepRed CSDS Failed POV POV Watch
69 DeepRed Disekt Failed POV POV Watch
69 DeepRed ForAllSecure Failed POV POV Watch
69 DeepRed Shellphish Failed POV through defenses POV Watch
69 DeepRed TECHx Failed POV POV Watch
70 CSDS CodeJitsu Failed POV POV Watch
70 CSDS DeepRed Failed POV POV Watch
70 CSDS Disekt Failed POV POV Watch
70 CSDS ForAllSecure Failed POV POV Watch
70 CSDS Shellphish Failed POV through defenses POV Watch
70 CSDS TECHx Failed POV POV Watch
70 DeepRed CodeJitsu Failed POV POV Watch
70 DeepRed CSDS Failed POV POV Watch
70 DeepRed Disekt Failed POV POV Watch
70 DeepRed ForAllSecure Failed POV POV Watch
70 DeepRed Shellphish Failed POV through defenses POV Watch
70 DeepRed TECHx Failed POV POV Watch
71 CSDS CodeJitsu Failed POV POV Watch
71 CSDS DeepRed Failed POV POV Watch
71 CSDS Disekt Failed POV POV Watch
71 CSDS ForAllSecure Failed POV POV Watch
71 CSDS Shellphish Failed POV through defenses POV Watch
71 CSDS TECHx Failed POV POV Watch
71 DeepRed CodeJitsu Failed POV POV Watch
71 DeepRed CSDS Failed POV POV Watch
71 DeepRed Disekt Failed POV POV Watch
71 DeepRed ForAllSecure Failed POV POV Watch
71 DeepRed Shellphish Failed POV through defenses POV Watch
71 DeepRed TECHx Failed POV POV Watch
72 CSDS CodeJitsu Failed POV POV Watch
72 CSDS DeepRed Failed POV POV Watch
72 CSDS Disekt Failed POV POV Watch
72 CSDS ForAllSecure Failed POV POV Watch
72 CSDS Shellphish Failed POV through defenses POV Watch
72 CSDS TECHx Failed POV POV Watch
72 DeepRed CodeJitsu Failed POV POV Watch
72 DeepRed CSDS Failed POV POV Watch
72 DeepRed Disekt Failed POV POV Watch
72 DeepRed ForAllSecure Failed POV POV Watch
72 DeepRed Shellphish Failed POV through defenses POV Watch
72 DeepRed TECHx Failed POV POV Watch
73 CodeJitsu Disekt Failed POV through defenses POV Watch
73 CSDS CodeJitsu Failed POV POV Watch
73 CSDS DeepRed Failed POV POV Watch
73 CSDS Disekt Failed POV through defenses POV Watch
73 CSDS ForAllSecure Failed POV POV Watch
73 CSDS Shellphish Failed POV through defenses POV Watch
73 CSDS TECHx Failed POV POV Watch
73 DeepRed CodeJitsu Failed POV POV Watch
73 DeepRed CSDS Failed POV POV Watch
73 DeepRed Disekt Failed POV through defenses POV Watch
73 DeepRed ForAllSecure Failed POV POV Watch
73 DeepRed Shellphish Failed POV through defenses POV Watch
73 DeepRed TECHx Failed POV POV Watch
74 CSDS CodeJitsu Failed POV POV Watch
74 CSDS DeepRed Failed POV POV Watch
74 CSDS Disekt Failed POV through defenses POV Watch
74 CSDS ForAllSecure Failed POV POV Watch
74 CSDS Shellphish Failed POV through defenses POV Watch
74 CSDS TECHx Failed POV POV Watch
74 DeepRed CodeJitsu Failed POV POV Watch
74 DeepRed CSDS Failed POV POV Watch
74 DeepRed Disekt Failed POV through defenses POV Watch
74 DeepRed ForAllSecure Failed POV POV Watch
74 DeepRed Shellphish Failed POV through defenses POV Watch
74 DeepRed TECHx Failed POV POV Watch

Curated by Lunge Technology, LLC. Questions or comments? Send us email