I have some legacy code that passes around a pointer to an internal data structure that the library uses to manipulate and check state variables. Thinking about refactoring this code, I became curious if creating a bunch of classes that are meant to only be used internally in my library would cause security concerns. Could others link in their own implementations of these methods? Say I have a Config class that reads an encrypted license and sets settings correctly. Would it be possible to manipulate this class somehow?

Here's some code I wrote to try initial feasibility


#include "shared.h"

Config::Config() : max_clients()


int Config::getMaxClients() const
    return max_clients;

void Config::setMaxClients(int num)
    max_clients = num;

I compiled this into a shared library with

g++ -c shared.cpp -fpic
g++ -shared -o libshared.so shared.o

Once compiled we can see what other people can see about our Config class in our library.

$ nm -C libshared.so
0000000000201030 B __bss_start
0000000000201030 b completed.7696
                 w __cxa_finalize
0000000000000780 t deregister_tm_clones
0000000000000810 t __do_global_dtors_aux
0000000000200e20 t __do_global_dtors_aux_fini_array_entry
0000000000201028 d __dso_handle
0000000000200e58 d _DYNAMIC
0000000000201030 D _edata
0000000000201038 B _end
00000000000008f8 T _fini
0000000000000850 t frame_dummy
0000000000200e18 t __frame_dummy_init_array_entry
0000000000000a50 r __FRAME_END__
0000000000201000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
0000000000000910 r __GNU_EH_FRAME_HDR
0000000000000720 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000007c0 t register_tm_clones
0000000000201030 d __TMC_END__
                 U operator delete(void*, unsigned long)
00000000000008de T Config::setMaxClients(int)
000000000000085a T Config::Config()
000000000000085a T Config::Config()
00000000000008a0 T Config::~Config()
0000000000000882 T Config::~Config()
0000000000000882 T Config::~Config()
00000000000008cc T Config::getMaxClients() const
0000000000200e48 V typeinfo for Config
0000000000000908 V typeinfo name for Config
0000000000200e28 V vtable for Config
                 U vtable for __cxxabiv1::__class_type_info

There's probably a lot more analysis I don't know about here.


With this information we could guess a bit about return types on setMaxClients and create our own implementation.

#include <iostream>

class Config {
    Config() {}
    void setMaxClients(int num);

void Config::setMaxClients(int num)
    std::cout << "do something bad" << std::endl;

I compiled this file with

g++ -c mal.cpp -fpic
g++ -shared -o libmal.so mal.o


class Config {
    virtual ~Config();
    int getMaxClients();
    void setMaxClients(int num);

int main()
    Config config;

    return 0;

Finally, I compiled main.cpp with linking my mal library first then shared like so

g++ main.cpp -lmal -lshared

This produced a binary which when run I get

$ LD_LIBRARY_PATH=. ./a.out
do something bad
*** stack smashing detected ***: <unknown> terminated
[1]    7842 abort (core dumped)  LD_LIBRARY_PATH=. ./a.out

Yes it crashed but I'm not more experienced to know where to go next. Is this not a security concern because you wouldn't actually be able to change any of the classes fields since you don't know the member variables? Or is there a concern here that requires best practices in C++?

1 Answers

robthebloke On

Your replacement class should ideally be the same size as the original class. The config in main.cpp has a virtual dtor, whereas the one in mal.cpp does not. This will cause the latter to be 8bytes larger (assuming 64bit OS), and will invariably lead to a problem on destruction of the class. If this is a real concern, a simple next step is to perform a checksum on the dll, and validate that at runtime (quit if checksum does not match). It wont help a great deal for someone who really cares though. If you know enough about asm, you can usually patch a binary exe with some no-ops until your check returns true.