Mixing
Exploiting c - linux setuid and system commands
I have the following code as an executable that I want to exploit for a course in order to spawn a shell with elevated privileges. I am a user of levelX and the executable has setgid of levelX+1. I am not allowed to alter any of the code.
As I do not have root privileges, setguid(0) fails. I was not able to change the return address of the function or main function. Could anyone point to the right direction?
int main (int argc, char** argv)
{
if (exec(argv[1]) != 0)
{
fprintf(stderr, "Cannot execute your commandn");
return -1;
}
return 0;
}
int exec(char *command)
{
FILE *f = NULL;
char entry[64];
char line[256];
f = fopen("log", "a");
if (f == NULL)
{
fprintf(stderr, "Can't open filen");
return -1;
}
snprintf(entry, 64, "%d: %sn", getuid(), command);
fprintf(f, entry, NULL);
fclose(f);
f = fopen("sudoers", "r");
if (f == NULL)
{
fprintf(stderr, "Can't openn");
return -1;
}
while(fgets(line, 256, f) != NULL)
{
if (atoi(line) == getuid())
{
if (setuid(0) == 0) {
system(command);
} else {
fprintf(stderr, "check permissionsn");
}
fclose(f);
return 0;
}
}
fprintf(stderr, "Errorn");
fclose(f);
return -1;
}
c linux security buffer-overflow
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
add a comment |
I have the following code as an executable that I want to exploit for a course in order to spawn a shell with elevated privileges. I am a user of levelX and the executable has setgid of levelX+1. I am not allowed to alter any of the code.
As I do not have root privileges, setguid(0) fails. I was not able to change the return address of the function or main function. Could anyone point to the right direction?
int main (int argc, char** argv)
{
if (exec(argv[1]) != 0)
{
fprintf(stderr, "Cannot execute your commandn");
return -1;
}
return 0;
}
int exec(char *command)
{
FILE *f = NULL;
char entry[64];
char line[256];
f = fopen("log", "a");
if (f == NULL)
{
fprintf(stderr, "Can't open filen");
return -1;
}
snprintf(entry, 64, "%d: %sn", getuid(), command);
fprintf(f, entry, NULL);
fclose(f);
f = fopen("sudoers", "r");
if (f == NULL)
{
fprintf(stderr, "Can't openn");
return -1;
}
while(fgets(line, 256, f) != NULL)
{
if (atoi(line) == getuid())
{
if (setuid(0) == 0) {
system(command);
} else {
fprintf(stderr, "check permissionsn");
}
fclose(f);
return 0;
}
}
fprintf(stderr, "Errorn");
fclose(f);
return -1;
}
c linux security buffer-overflow
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
Post complete code with appropriate headers.
– EsmaeelE
Nov 22 '18 at 12:26
This looks like you have partially sanitized/anonymized the code, or tried to? Please provide a working code, which you can build yourself. For example, what islog_entry?
– hyde
Nov 22 '18 at 12:28
Both correct! Edited the code. It compiles and runs
– NotApplicable
Nov 22 '18 at 12:32
What do you exactly mean with LevelX and LevelX+1. What's the role of levels in your explanation? In plain UNIX, there's only two levels, user and root level, the first is subject to permissions, the later isn't. Not n levels up, sorry.
– Luis Colorado
Nov 27 '18 at 8:33
I mean different levels without any of the levels being root.
– NotApplicable
Dec 11 '18 at 20:24
add a comment |
I have the following code as an executable that I want to exploit for a course in order to spawn a shell with elevated privileges. I am a user of levelX and the executable has setgid of levelX+1. I am not allowed to alter any of the code.
As I do not have root privileges, setguid(0) fails. I was not able to change the return address of the function or main function. Could anyone point to the right direction?
int main (int argc, char** argv)
{
if (exec(argv[1]) != 0)
{
fprintf(stderr, "Cannot execute your commandn");
return -1;
}
return 0;
}
int exec(char *command)
{
FILE *f = NULL;
char entry[64];
char line[256];
f = fopen("log", "a");
if (f == NULL)
{
fprintf(stderr, "Can't open filen");
return -1;
}
snprintf(entry, 64, "%d: %sn", getuid(), command);
fprintf(f, entry, NULL);
fclose(f);
f = fopen("sudoers", "r");
if (f == NULL)
{
fprintf(stderr, "Can't openn");
return -1;
}
while(fgets(line, 256, f) != NULL)
{
if (atoi(line) == getuid())
{
if (setuid(0) == 0) {
system(command);
} else {
fprintf(stderr, "check permissionsn");
}
fclose(f);
return 0;
}
}
fprintf(stderr, "Errorn");
fclose(f);
return -1;
}
c linux security buffer-overflow
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
I have the following code as an executable that I want to exploit for a course in order to spawn a shell with elevated privileges. I am a user of levelX and the executable has setgid of levelX+1. I am not allowed to alter any of the code.
As I do not have root privileges, setguid(0) fails. I was not able to change the return address of the function or main function. Could anyone point to the right direction?
int main (int argc, char** argv)
{
if (exec(argv[1]) != 0)
{
fprintf(stderr, "Cannot execute your commandn");
return -1;
}
return 0;
}
int exec(char *command)
{
FILE *f = NULL;
char entry[64];
char line[256];
f = fopen("log", "a");
if (f == NULL)
{
fprintf(stderr, "Can't open filen");
return -1;
}
snprintf(entry, 64, "%d: %sn", getuid(), command);
fprintf(f, entry, NULL);
fclose(f);
f = fopen("sudoers", "r");
if (f == NULL)
{
fprintf(stderr, "Can't openn");
return -1;
}
while(fgets(line, 256, f) != NULL)
{
if (atoi(line) == getuid())
{
if (setuid(0) == 0) {
system(command);
} else {
fprintf(stderr, "check permissionsn");
}
fclose(f);
return 0;
}
}
fprintf(stderr, "Errorn");
fclose(f);
return -1;
}
c linux security buffer-overflow
c linux security buffer-overflow
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
edited Nov 22 '18 at 13:18
NotApplicable
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
asked Nov 22 '18 at 12:12
NotApplicableNotApplicable
366
366
Post complete code with appropriate headers.
– EsmaeelE
Nov 22 '18 at 12:26
This looks like you have partially sanitized/anonymized the code, or tried to? Please provide a working code, which you can build yourself. For example, what islog_entry?
– hyde
Nov 22 '18 at 12:28
Both correct! Edited the code. It compiles and runs
– NotApplicable
Nov 22 '18 at 12:32
What do you exactly mean with LevelX and LevelX+1. What's the role of levels in your explanation? In plain UNIX, there's only two levels, user and root level, the first is subject to permissions, the later isn't. Not n levels up, sorry.
– Luis Colorado
Nov 27 '18 at 8:33
I mean different levels without any of the levels being root.
– NotApplicable
Dec 11 '18 at 20:24
add a comment |
Post complete code with appropriate headers.
– EsmaeelE
Nov 22 '18 at 12:26
This looks like you have partially sanitized/anonymized the code, or tried to? Please provide a working code, which you can build yourself. For example, what islog_entry?
– hyde
Nov 22 '18 at 12:28
Both correct! Edited the code. It compiles and runs
– NotApplicable
Nov 22 '18 at 12:32
What do you exactly mean with LevelX and LevelX+1. What's the role of levels in your explanation? In plain UNIX, there's only two levels, user and root level, the first is subject to permissions, the later isn't. Not n levels up, sorry.
– Luis Colorado
Nov 27 '18 at 8:33
I mean different levels without any of the levels being root.
– NotApplicable
Dec 11 '18 at 20:24
Post complete code with appropriate headers.
– EsmaeelE
Nov 22 '18 at 12:26
Post complete code with appropriate headers.
– EsmaeelE
Nov 22 '18 at 12:26
This looks like you have partially sanitized/anonymized the code, or tried to? Please provide a working code, which you can build yourself. For example, what is
log_entry?– hyde
Nov 22 '18 at 12:28
This looks like you have partially sanitized/anonymized the code, or tried to? Please provide a working code, which you can build yourself. For example, what is
log_entry?– hyde
Nov 22 '18 at 12:28
Both correct! Edited the code. It compiles and runs
– NotApplicable
Nov 22 '18 at 12:32
Both correct! Edited the code. It compiles and runs
– NotApplicable
Nov 22 '18 at 12:32
What do you exactly mean with LevelX and LevelX+1. What's the role of levels in your explanation? In plain UNIX, there's only two levels, user and root level, the first is subject to permissions, the later isn't. Not n levels up, sorry.
– Luis Colorado
Nov 27 '18 at 8:33
What do you exactly mean with LevelX and LevelX+1. What's the role of levels in your explanation? In plain UNIX, there's only two levels, user and root level, the first is subject to permissions, the later isn't. Not n levels up, sorry.
– Luis Colorado
Nov 27 '18 at 8:33
I mean different levels without any of the levels being root.
– NotApplicable
Dec 11 '18 at 20:24
I mean different levels without any of the levels being root.
– NotApplicable
Dec 11 '18 at 20:24
add a comment |
2 Answers
2
active
oldest
votes
From the code you posted, it appears you are supposed to write your own sudoers file to any directory you have write access to, then run this program in that directory, so it reads your file.
So, simply write your own UID to this fake sudoers file, and then give a command parameter such as bash to get a shell. There's no need to do any buffer overflow exploitation.
Presumably the real exploitable program has suid bit set in the file permissions, so it can perform the setuid(0) call. I guess the purpose of the exercise is to demonstrate how all input needs to be sanitized when you are dealing with suid programs, including things like relative paths (which effectively take current working directory as input) like any user-supplied paths and other input.
But, since the program only has setgid bit (as said in comment), you need find something you do with just the group id. That something could be that log file write. You could create a symbolic link with file name log, pointing to whatever file you want to append to, which that group has write permissions for. Also, that file needs to have format such, that the log line format does not make the file corrupted. Remember, you can put newlines etc into command line arguments!
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
Ah, then you need a way to make something happen beforesetuidcall... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.
– hyde
Nov 22 '18 at 12:41
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
1
If you have trouble finding possible exploitable files, checkout outfindcommand, it has option to search for files with certain group.
– hyde
Nov 22 '18 at 16:42
1
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably justln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.
– Nominal Animal
Nov 23 '18 at 12:37
|
show 3 more comments
After all it was a format string exploit on fprintf(f, entry, NULL); inside int exec(char *command) where you overwrite the return address with %n format.
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430763%2fexploiting-c-linux-setuid-and-system-commands%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
From the code you posted, it appears you are supposed to write your own sudoers file to any directory you have write access to, then run this program in that directory, so it reads your file.
So, simply write your own UID to this fake sudoers file, and then give a command parameter such as bash to get a shell. There's no need to do any buffer overflow exploitation.
Presumably the real exploitable program has suid bit set in the file permissions, so it can perform the setuid(0) call. I guess the purpose of the exercise is to demonstrate how all input needs to be sanitized when you are dealing with suid programs, including things like relative paths (which effectively take current working directory as input) like any user-supplied paths and other input.
But, since the program only has setgid bit (as said in comment), you need find something you do with just the group id. That something could be that log file write. You could create a symbolic link with file name log, pointing to whatever file you want to append to, which that group has write permissions for. Also, that file needs to have format such, that the log line format does not make the file corrupted. Remember, you can put newlines etc into command line arguments!
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
Ah, then you need a way to make something happen beforesetuidcall... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.
– hyde
Nov 22 '18 at 12:41
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
1
If you have trouble finding possible exploitable files, checkout outfindcommand, it has option to search for files with certain group.
– hyde
Nov 22 '18 at 16:42
1
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably justln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.
– Nominal Animal
Nov 23 '18 at 12:37
|
show 3 more comments
From the code you posted, it appears you are supposed to write your own sudoers file to any directory you have write access to, then run this program in that directory, so it reads your file.
So, simply write your own UID to this fake sudoers file, and then give a command parameter such as bash to get a shell. There's no need to do any buffer overflow exploitation.
Presumably the real exploitable program has suid bit set in the file permissions, so it can perform the setuid(0) call. I guess the purpose of the exercise is to demonstrate how all input needs to be sanitized when you are dealing with suid programs, including things like relative paths (which effectively take current working directory as input) like any user-supplied paths and other input.
But, since the program only has setgid bit (as said in comment), you need find something you do with just the group id. That something could be that log file write. You could create a symbolic link with file name log, pointing to whatever file you want to append to, which that group has write permissions for. Also, that file needs to have format such, that the log line format does not make the file corrupted. Remember, you can put newlines etc into command line arguments!
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
Ah, then you need a way to make something happen beforesetuidcall... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.
– hyde
Nov 22 '18 at 12:41
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
1
If you have trouble finding possible exploitable files, checkout outfindcommand, it has option to search for files with certain group.
– hyde
Nov 22 '18 at 16:42
1
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably justln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.
– Nominal Animal
Nov 23 '18 at 12:37
|
show 3 more comments
From the code you posted, it appears you are supposed to write your own sudoers file to any directory you have write access to, then run this program in that directory, so it reads your file.
So, simply write your own UID to this fake sudoers file, and then give a command parameter such as bash to get a shell. There's no need to do any buffer overflow exploitation.
Presumably the real exploitable program has suid bit set in the file permissions, so it can perform the setuid(0) call. I guess the purpose of the exercise is to demonstrate how all input needs to be sanitized when you are dealing with suid programs, including things like relative paths (which effectively take current working directory as input) like any user-supplied paths and other input.
But, since the program only has setgid bit (as said in comment), you need find something you do with just the group id. That something could be that log file write. You could create a symbolic link with file name log, pointing to whatever file you want to append to, which that group has write permissions for. Also, that file needs to have format such, that the log line format does not make the file corrupted. Remember, you can put newlines etc into command line arguments!
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
From the code you posted, it appears you are supposed to write your own sudoers file to any directory you have write access to, then run this program in that directory, so it reads your file.
So, simply write your own UID to this fake sudoers file, and then give a command parameter such as bash to get a shell. There's no need to do any buffer overflow exploitation.
Presumably the real exploitable program has suid bit set in the file permissions, so it can perform the setuid(0) call. I guess the purpose of the exercise is to demonstrate how all input needs to be sanitized when you are dealing with suid programs, including things like relative paths (which effectively take current working directory as input) like any user-supplied paths and other input.
But, since the program only has setgid bit (as said in comment), you need find something you do with just the group id. That something could be that log file write. You could create a symbolic link with file name log, pointing to whatever file you want to append to, which that group has write permissions for. Also, that file needs to have format such, that the log line format does not make the file corrupted. Remember, you can put newlines etc into command line arguments!
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
edited Nov 22 '18 at 12:47
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
answered Nov 22 '18 at 12:33
hydehyde
31.6k1588131
31.6k1588131
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
Ah, then you need a way to make something happen beforesetuidcall... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.
– hyde
Nov 22 '18 at 12:41
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
1
If you have trouble finding possible exploitable files, checkout outfindcommand, it has option to search for files with certain group.
– hyde
Nov 22 '18 at 16:42
1
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably justln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.
– Nominal Animal
Nov 23 '18 at 12:37
|
show 3 more comments
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
Ah, then you need a way to make something happen beforesetuidcall... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.
– hyde
Nov 22 '18 at 12:41
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
1
If you have trouble finding possible exploitable files, checkout outfindcommand, it has option to search for files with certain group.
– hyde
Nov 22 '18 at 16:42
1
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably justln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.
– Nominal Animal
Nov 23 '18 at 12:37
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
I did create a file with my guid and bypassed this check. The exploitable program has sgid: -rwxr-sr-x but the file's group is not the root
– NotApplicable
Nov 22 '18 at 12:37
Ah, then you need a way to make something happen before
setuid call... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.– hyde
Nov 22 '18 at 12:41
Ah, then you need a way to make something happen before
setuid call... Hint: you program writes to a log with the group of the binary... That's what you are supposed to exploit then, probably.– hyde
Nov 22 '18 at 12:41
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
Perfect! Thanks!
– NotApplicable
Nov 22 '18 at 13:05
1
1
If you have trouble finding possible exploitable files, checkout out
find command, it has option to search for files with certain group.– hyde
Nov 22 '18 at 16:42
If you have trouble finding possible exploitable files, checkout out
find command, it has option to search for files with certain group.– hyde
Nov 22 '18 at 16:42
1
1
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably just
ln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.– Nominal Animal
Nov 23 '18 at 12:37
@NotApplicable: Since the program does not work for anyone as intended (unless the executable group is root), I suspect the solution sought after is much simpler than you're thinking: it is probably just
ln -s sudoers log && /path/to/that/executable bash, to give you the privileged shell based on a sudoers file under your own control; even if it is privileged by default, having the log output directed to the sudoers ensures the current uid will be listed there. You could ask your lecturer whether the group ownership of the executable is as designed, or just an oversight.– Nominal Animal
Nov 23 '18 at 12:37
|
show 3 more comments
After all it was a format string exploit on fprintf(f, entry, NULL); inside int exec(char *command) where you overwrite the return address with %n format.
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
add a comment |
After all it was a format string exploit on fprintf(f, entry, NULL); inside int exec(char *command) where you overwrite the return address with %n format.
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
add a comment |
After all it was a format string exploit on fprintf(f, entry, NULL); inside int exec(char *command) where you overwrite the return address with %n format.
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
After all it was a format string exploit on fprintf(f, entry, NULL); inside int exec(char *command) where you overwrite the return address with %n format.
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
answered Dec 11 '18 at 20:27
NotApplicableNotApplicable
366
366
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430763%2fexploiting-c-linux-setuid-and-system-commands%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Post complete code with appropriate headers.
– EsmaeelE
Nov 22 '18 at 12:26
This looks like you have partially sanitized/anonymized the code, or tried to? Please provide a working code, which you can build yourself. For example, what is
log_entry?– hyde
Nov 22 '18 at 12:28
Both correct! Edited the code. It compiles and runs
– NotApplicable
Nov 22 '18 at 12:32
What do you exactly mean with LevelX and LevelX+1. What's the role of levels in your explanation? In plain UNIX, there's only two levels, user and root level, the first is subject to permissions, the later isn't. Not n levels up, sorry.
– Luis Colorado
Nov 27 '18 at 8:33
I mean different levels without any of the levels being root.
– NotApplicable
Dec 11 '18 at 20:24