"Nick Davis" firstname.lastname@example.org
Narf Industries (NRFIN)
Ski resorts now have gates equipped with RFID sensors at every lift entrance that scan riders to verify their lift pass before the rider can board the lift. The side benefit of this technology is that resorts can accurately track rider numbers on each lift to glean important statistics.
Our exciting new software, Resort Modeller, works on the back-end to allow Resort staff to model different lift usage scenarios based on varying numbers of riders. This will help Resort owners make important planning and staffing decisions.
The Resort Model is comprised of lifts, trails, and riders. Deciders are used as nodes to connect lifts and trails. Riders can be skiers or snowboarders and they are pre-defined to have a certain amount of energy, which simulates how many trails they will ride before quitting for the day. Lifts have a chair capacity of either 2 or 4 riders per chair and have a static number of chairs. Trails have a difficulty rating from 1 (Easiest) to 5 (Hardest), this will subtract 1-5 units from the riders energy when the rider completes the trail. Trails also have a length.
Load Resort Digraph: A directed graph of lifts and trails is used to define the resort layout. If one already exists, it is replaced.
Load Rider Group: A group of riders is loaded into the model.
Load Rider Single: A single rider is loaded into the model.
Unload Riders: All riders are unloaded from the model (deleted). This will also reset the simulation.
Start Simulation: Start the simulation and run it for the specified number of steps. All riders will start via the queue of the first lift.
Reset Simulation: Reset all stats. Move all Riders to the Resort's list of available riders.
Lift Stats: Request the counts for how many total riders have boarded each lift.
Trail Stats: Request the counts for how many total riders have completed each trail.
Rider Stats: Request the counts for the number of trails each rider has completed and their energy level.
The code that performs a health check on the riders (rider.c:36) simulates code that was not finished during development or modification. If we make the assumption that the original code just checked every user and the new code was designed/updated to only check riders that are out of energy, we can see how this could happen. On line 43, there is an accidental incrementing of the results pointer. And on line 45 the developer forgot to delete the original line of code that checked every rider. The combination of those 2 lines results in overwritting the riders's health_check function pointer with the health check result value. This value is user controlled along with the rider's ID, so the next time this rider enters the simulation (after reset_simulation and then start_simulation), and they run out of energy, the health_check function will be an invalid pointer causing Type 1 POV.
Untrusted Pointer Dereference Incorrect Pointer Scaling
CWE-468: Incorrect Pointer Scaling CWE-822: Untrusted Pointer Dereference
Curated by Lunge Technology, LLC. Questions or comments? Send us email