Yes. Multiple vulnerabilities have been discovered in OpenSSL 1.0.0, including high-profile ones like Heartbleed (CVE-2014-0160), TLS padding oracle (CVE-2016-2107), and others. This version is considered insecure and deprecated. Immediate upgrade is strongly recommended.
Function ghidra_open_server called with arguments: {"filepath":"/sandbox/libssl.so.1.0.0"}
Tool result
[
{
"type": "text",
"text": "Success"
}
]Function ghidra_search_functions_by_name called with arguments: {"filepath":"/sandbox/libssl.so.1.0.0","query":"heartbeat"}
Tool result
[
{
"type": "text",
"text": "dtls1_heartbeat @ 00140880"
},
{
"type": "text",
"text": "dtls1_process_heartbeat @ 001406e0"
},
{
"type": "text",
"text": "tls1_heartbeat @ 00134420"
},
{
"type": "text",
"text": "tls1_process_heartbeat @ 00134290"
}
]Function ghidra_decompile_function called with arguments: {"filepath":"/sandbox/libssl.so.1.0.0","name_or_address":"tls1_heartbeat"}
Tool result
[
{
"type": "text",
"text": "\nint tls1_heartbeat(SSL *param_1)\n\n{\n uint uVar1;\n int iVar2;\n undefined1 *buf;\n \n if (((ulong)param_1->srtp_profile & 3) == 1) {\n if (*(int *)((long)¶m_1->srtp_profile + 4) == 0) {\n uVar1 = SSL_state(param_1);\n if (((uVar1 & 0x3000) == 0) && (param_1->in_handshake == 0)) {\n buf = (undefined1 *)CRYPTO_malloc(0x25,\"t1_lib.c\",0xa6a);\n *buf = 1;\n buf[1] = 0;\n buf[2] = 0x12;\n buf[3] = (char)(param_1->tlsext_heartbeat >> 8);\n buf[4] = (char)param_1->tlsext_heartbeat;\n RAND_pseudo_bytes(buf + 5,0x10);\n RAND_pseudo_bytes(buf + 0x15,0x10);\n iVar2 = ssl3_write_bytes(param_1,0x18,buf,0x25);\n if (-1 < iVar2) {\n if (param_1->msg_callback != (_func_3150 *)0x0) {\n (*param_1->msg_callback)\n (1,param_1->version,0x18,buf,0x25,param_1,param_1->msg_callback_arg);\n }\n *(undefined4 *)((long)¶m_1->srtp_profile + 4) = 1;\n }\n CRYPTO_free(buf);\n }\n else {\n ERR_put_error(0x14,0x13b,0xf4,\"t1_lib.c\",0xa58);\n iVar2 = -1;\n }\n }\n else {\n ERR_put_error(0x14,0x13b,0x16e,\"t1_lib.c\",0xa51);\n iVar2 = -1;\n }\n }\n else {\n ERR_put_error(0x14,0x13b,0x16d,\"t1_lib.c\",0xa4a);\n iVar2 = -1;\n }\n return iVar2;\n}\n\n"
}
]Function ghidra_decompile_function called with arguments: {"filepath":"/sandbox/libssl.so.1.0.0","name_or_address":"tls1_process_heartbeat"}
Tool result
[
{
"type": "text",
"text": "\nint tls1_process_heartbeat(undefined4 *param_1)\n\n{\n char cVar1;\n char cVar2;\n char cVar3;\n char *pcVar4;\n int iVar5;\n undefined1 *ptr;\n void *pvVar6;\n uint uVar7;\n int num;\n \n pcVar4 = *(char **)(*(long *)(param_1 + 0x20) + 0x130);\n cVar1 = pcVar4[1];\n cVar2 = pcVar4[2];\n cVar3 = *pcVar4;\n uVar7 = (uint)CONCAT11(cVar1,cVar2);\n if (*(code **)(param_1 + 0x26) != (code *)0x0) {\n (**(code **)(param_1 + 0x26))\n (0,*param_1,0x18,pcVar4,*(undefined4 *)(*(long *)(param_1 + 0x20) + 0x124),param_1,\n *(undefined8 *)(param_1 + 0x28));\n }\n if (cVar3 == '\\x01') {\n num = uVar7 + 0x13;\n ptr = (undefined1 *)CRYPTO_malloc(num,\"t1_lib.c\",0xa14);\n *ptr = 2;\n ptr[1] = cVar1;\n ptr[2] = cVar2;\n pvVar6 = memcpy(ptr + 3,pcVar4 + 3,(ulong)uVar7);\n RAND_pseudo_bytes((uchar *)((long)pvVar6 + (ulong)uVar7),0x10);\n iVar5 = ssl3_write_bytes(param_1,0x18,ptr,num);\n if (-1 < iVar5) {\n if (*(code **)(param_1 + 0x26) != (code *)0x0) {\n (**(code **)(param_1 + 0x26))\n (1,*param_1,0x18,ptr,num,param_1,*(undefined8 *)(param_1 + 0x28));\n }\n CRYPTO_free(ptr);\n return 0;\n }\n CRYPTO_free(ptr);\n }\n else {\n iVar5 = 0;\n if (cVar3 == '\\x02') {\n if ((uVar7 == 0x12) && (param_1[0xa8] == (uint)CONCAT11(pcVar4[3],pcVar4[4]))) {\n param_1[0xa7] = 0;\n param_1[0xa8] = param_1[0xa8] + 1;\n iVar5 = 0;\n }\n }\n }\n return iVar5;\n}\n\n"
}
]Yes. Heartbleed vulnerability code (improper length validation in tls1_process_heartbeat) is present in this binary.
- Function: tls1_process_heartbeat
- Evidence:
- Lacks boundary/length checks:
- Allocates buffer: ptr = CRYPTO_malloc(num,...); num = uVar7 + 0x13;
- Copies payload: memcpy(ptr + 3, pcVar4 + 3, (ulong)uVar7);
- uVar7 value is attacker-controlled, parsed from incoming heartbeat message
- No validation that uVar7 (payload length) is less than or equal to the received message size, enabling out-of-bounds read
- Lacks boundary/length checks:
- Location: tls1_process_heartbeat @ 0x00134290, decompilation confirms the vulnerable logic
- Conclusion: Vulnerability matches CVE-2014-0160 (“Heartbleed”) pattern exactly