Rank these code function scenarios from highest risk (5) to lowest (1) based on
ID: 3679797 • Letter: R
Question
Rank these code function scenarios from highest risk (5) to lowest (1) based on the information given:
a._____ The funcation takes direct input from the user and does not do bounds checking on the input and the application does not run with "setuid"
b_____ The funcation takes direct input from the user and does not do bounds checking on the input and the application runs "setuid root"
c_____ The funcation does not take direct input from the user and does bounds checking on the input and the application runs "setuid root"
d____ The funcation does not take direct input from the user and does not do bounds checking on the input and the application runs "setuid root"
e____ The funcation takes direct input from the user and does bounds checking on the input and the application runs "setuid root"
Explanation / Answer
SETUID means that the executable can run under different permissions than the user who has executed it.
Certain applications are set like this so the users can run with low permissions but a specific application they need to run with higher permissions can be.
SETUID 0 or root means that when the program is run it is as if root ran it - which leaves you open to all the usual security risks of running something at high permission levels - it could potentially do anything to your system - so generally the number of applications that require SETUID should be minimised on a Unix box. Most security audits of Unix machines include looking for SETUID and SETGID files that are world writeable as they present a high risk.
a.___3__ The funcation takes direct input from the user and does not do bounds checking on the input and the application does not run with "setuid" // even if the function is talking direct input but not running setuid is less risk to system
b___5__ The funcation takes direct input from the user and does not do bounds checking on the input and the application runs "setuid root" // since direct input is take and bound checking is not done, Setuid can do anything to the system which can be very hazardous
c__1___ The funcation does not take direct input from the user and does bounds checking on the input and the application runs "setuid root" // this is most risk free among all as bound checking is done bfore setuid
d__4__ The funcation does not take direct input from the user and does not do bounds checking on the input and the application runs "setuid root" // since bound checking is not done, risk is high because setuid is implemented without bound checking
e__2__ The funcation takes direct input from the user and does bounds checking on the input and the application runs "setuid root" // this is the second most risk free since function is taking direct input but is doing bound checking before execution of Setuid
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.