mz-automation / libiec61850

Official repository for libIEC61850, the open-source library for the IEC 61850 protocols
http://libiec61850.com/libiec61850
GNU General Public License v3.0
857 stars 459 forks source link

SEGV in server_example_61400_25.c, server_example_basic_io.c etc after fuzzing on the updated IEC61850 #135

Closed HopefulWei closed 5 years ago

HopefulWei commented 5 years ago

Hi team, When I made a fuzzing test on libIEC61850, I found a new problem. The object of my fuzzing test is libIEC61850 after the update. The initial problem can be found here. Their are SEGV in server_example_61400_25, server_example_basic_io, etc. libIEC61850 1.3.2 and 1.3.3 version has this problem.

the gdb's error

Thread 3 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xc07 of process 1158]
0x0007190c in private_ClientConnection_getTasksCount (self=0x0)
    at src/iec61850/server/impl/client_connection.c:76
76  src/iec61850/server/impl/client_connection.c: No such file or directory.

The ASAN's error:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==1312==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000 (pc 0x001634cc bp 0xb04a0df8 sp 0xb04a0de0 T1277)
==1312==The signal is caused by a READ memory access.
==1312==Hint: address points to the zero page.
    #0 0x1634cb in private_ClientConnection_getTasksCount client_connection.c:76
    #1 0x153f7d in mmsConnectionHandler mms_mapping.c:2409
    #2 0x10c0b4 in isoConnectionIndicationHandler mms_server.c:420
    #3 0x1459de in IsoServer_closeConnection iso_server.c:768
    #4 0x144cd0 in finalizeIsoConnection iso_connection.c:98
    #5 0x144c89 in handleTcpConnection iso_connection.c:436
    #6 0x167bd0 in destroyAutomaticThread thread_bsd.c:89
    #7 0x33ac4a in __asan::AsanThread::ThreadStart(unsigned long long, __sanitizer::atomic_uintptr_t*) (libclang_rt.asan_osx_dynamic.dylib:i386+0x5dc4a)
    #8 0x327827 in asan_thread_start(void*) (libclang_rt.asan_osx_dynamic.dylib:i386+0x4a827)
    #9 0xa75a34d4 in _pthread_body (libsystem_pthread.dylib:i386+0x34d4)
    #10 0xa75a3379 in _pthread_start (libsystem_pthread.dylib:i386+0x3379)
    #11 0xa75a2a55 in thread_start (libsystem_pthread.dylib:i386+0x2a55)

==1312==Register values:
eax = 0x00000000  ebx = 0x004f0f10  ecx = 0x00000000  edx = 0x02561c70  
edi = 0x00000000  esi = 0x00000000  ebp = 0xb04a0df8  esp = 0xb04a0de0  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV client_connection.c:76 in private_ClientConnection_getTasksCount
Thread T1277 created by T1 here:
    #0 0x3276d3 in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:i386+0x4a6d3)
    #1 0x167b4b in Thread_start thread_bsd.c:100
    #2 0x144c3a in IsoConnection_create iso_connection.c:513
    #3 0x145cc5 in handleIsoConnections iso_server.c:404
    #4 0x145355 in isoServerThread iso_server.c:491
    #5 0x33ac4a in __asan::AsanThread::ThreadStart(unsigned long long, __sanitizer::atomic_uintptr_t*) (libclang_rt.asan_osx_dynamic.dylib:i386+0x5dc4a)
    #6 0x327827 in asan_thread_start(void*) (libclang_rt.asan_osx_dynamic.dylib:i386+0x4a827)
    #7 0xa75a34d4 in _pthread_body (libsystem_pthread.dylib:i386+0x34d4)
    #8 0xa75a3379 in _pthread_start (libsystem_pthread.dylib:i386+0x3379)
    #9 0xa75a2a55 in thread_start (libsystem_pthread.dylib:i386+0x2a55)

Thread T1 created by T0 here:
    #0 0x3276d3 in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:i386+0x4a6d3)
    #1 0x167b92 in Thread_start thread_bsd.c:104
    #2 0x1452d8 in IsoServer_startListening iso_server.c:609
    #3 0x10bfa2 in MmsServer_startListening mms_server.c:437
    #4 0x16410c in IedServer_start ied_server.c:598
    #5 0xf38ac in main server_example_basic_io.c:137
    #6 0xa7292610 in start (libdyld.dylib:i386+0x1610)

==1312==ABORTING
Abort trap: 6

The problematic code:

ClientConnection
private_ClientConnection_create(void* serverConnectionHandle)
{
    ClientConnection self = (ClientConnection) GLOBAL_MALLOC(sizeof(struct sClientConnection));

#if (CONFIG_MMS_THREADLESS_STACK != 1)
    self->tasksCountMutex = Semaphore_create(1);
#endif

    self->tasksCount = 0;
    self->serverConnectionHandle = serverConnectionHandle;

    return self;
}

How to trigger it ?

MMS_update.py

# sudo python MMS_update.py -ip 127.0.0.1
Please input byte number:
5

You can see there.

New problems have arisen in the process of fuzzy testing

The initial problem can be found here. When I made a fuzzing test on libIEC61850 after being updated COTP Module, I Encountered the problem above.

HopefulWei commented 5 years ago

This time my fuzzing bytes is the bytes after the COTP including IEC_Presentation bytes and MMS bytes.

mzillgith commented 5 years ago

Thanks! I am trying your new test program.

mzillgith commented 5 years ago

After running MMS_update.py a few hours I was not able to reproduce the issue. Maybe the problem is solved by some of the latest updates? Or did you use some special configuration option?

mzillgith commented 5 years ago

Ok. Now I can reproduce when setting CONFIG_MMS_SINGLE_THREADED to 0.

mzillgith commented 5 years ago

Should be fixed now.

HopefulWei commented 5 years ago

OK

attritionorg commented 5 years ago

@mzillgith can you link to the fixing commit please?