[libmicrohttpd] libmicrohttpd is crashing during security test

2018-05-22 Thread Purna Chandra Jena 
Hi,

I am Purna from India.
I got this mailing list from libmicrohttpd info page and would like to
discuss with you about a crash that we are getting from libmicrohttpd
application during our security testing.

Version we are using:  libmicrohttpd-0.9.50-1.el7.centos.x86_64.rpm



Our application is using libmicrohttpd interface to receive http request.
When we are doing security testing on our application, we got a crash with
the following stack trace.

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x7fff7279c700 (LWP 31873)]

0x76add570 in MHD_http_unescape () from /lib64/libmicrohttpd.so.12

(gdb) bt
#0  0x76add570 in MHD_http_unescape () from
/lib64/libmicrohttpd.so.12
#1  0x76ad6172 in MHD_connection_handle_idle () from
/lib64/libmicrohttpd.so.12
#2  0x76ad6c25 in call_handlers () from /lib64/libmicrohttpd.so.12
#3  0x76ad8d2e in MHD_handle_connection () from
/lib64/libmicrohttpd.so.12
#4  0x7609ae25 in start_thread () from /lib64/libpthread.so.0
#5  0x75dc834d in clone () from /lib64/libc.so.6
(gdb)

Looking at the below statements, the crash is happening in method
*http_unescape*, possibly the webserver is trying to decode the received
messages which is not encoded already and its crashing I guess. Any
thoughts around this?


from google, i have seen that  MHD_http_unescape () method is having issues
earlier, which is fixed in version 0.9.32.

But we are still seeing this issue, even if we are using version 0.9.50.


Do you have any other suggestions for us to try out?



Are we missing any other dependant library or configuration for
*libmicrohttpd*?

Any help around this will be deeply appreciated.


-- 
Regards
Purna

Re: [libmicrohttpd] libmicrohttpd is crashing during security test

2018-05-22 Thread silvioprog 
Hello Purna, welcome to the list. :-)

Could you try the MHD version 0.9.59? I'm not familiar with CentOS, but I
think we can build latest MHD release easily from sources in that.

On Tue, May 22, 2018 at 3:30 AM, Purna Chandra Jena 
wrote:

> Hi,
>
> I am Purna from India.
> I got this mailing list from libmicrohttpd info page and would like to
> discuss with you about a crash that we are getting from libmicrohttpd
> application during our security testing.
>
> Version we are using:  libmicrohttpd-0.9.50-1.el7.centos.x86_64.rpm
> 
>
>
> Our application is using libmicrohttpd interface to receive http request.
> When we are doing security testing on our application, we got a crash with
> the following stack trace.
>
> Program received signal SIGSEGV, Segmentation fault.
>
> [Switching to Thread 0x7fff7279c700 (LWP 31873)]
>
> 0x76add570 in MHD_http_unescape () from /lib64/libmicrohttpd.so.12
>
> (gdb) bt
> #0  0x76add570 in MHD_http_unescape () from
> /lib64/libmicrohttpd.so.12
> #1  0x76ad6172 in MHD_connection_handle_idle () from
> /lib64/libmicrohttpd.so.12
> #2  0x76ad6c25 in call_handlers () from /lib64/libmicrohttpd.so.12
> #3  0x76ad8d2e in MHD_handle_connection () from
> /lib64/libmicrohttpd.so.12
> #4  0x7609ae25 in start_thread () from /lib64/libpthread.so.0
> #5  0x75dc834d in clone () from /lib64/libc.so.6
> (gdb)
>
> Looking at the below statements, the crash is happening in method
> *http_unescape*, possibly the webserver is trying to decode the received
> messages which is not encoded already and its crashing I guess. Any
> thoughts around this?
>
>
> from google, i have seen that  MHD_http_unescape () method is having
> issues earlier, which is fixed in version 0.9.32.
>
> But we are still seeing this issue, even if we are using version 0.9.50.
>
>
> Do you have any other suggestions for us to try out?
>
>
>
> Are we missing any other dependant library or configuration for
> *libmicrohttpd*?
>
> Any help around this will be deeply appreciated.
>
>
> --
> Regards
> Purna
>

-- 
Silvio Clécio

[libmicrohttpd] Using GnuTLS with GNUTLS_CRD_PSK and AES-256-GCM, SHA384

2018-05-22 Thread Tal Maoz (tmaoz) 
Hey guys,

I hope someone can help with this as it is pretty urgent.
I'm trying to build a simple secure server over libmicrohttpd.
I compiled version 0.9.59 with libgnutls 3.5.18.
I'm trying to use TLS-PSK with AES-256-GCM and SHA384 but I get an error:

Ø  Error: invalid credentials type 4 specified.

My code:

daemon = MHD_start_daemon(MHD_USE_THREAD_PER_CONNECTION | MHD_USE_SSL | 
MHD_USE_DEBUG,
   arguments.port_arg,
   NULL,
   NULL,
   &request_handler,
   NULL,
   MHD_OPTION_CONNECTION_TIMEOUT, 256,
   MHD_OPTION_HTTPS_CRED_TYPE, GNUTLS_CRD_PSK,
   MHD_OPTION_HTTPS_PRIORITIES, 
"NONE:+AES-256-GCM:+SHA384",
   MHD_OPTION_HTTPS_MEM_KEY, key_pem,
   MHD_OPTION_HTTPS_MEM_CERT, cert_pem,
   MHD_OPTION_END);

I looked into the source code of libmicrohttps and in microhttpd/daemon.c:576 I 
see that, for some reason, if anything other than GNUTLS_CRD_CERTIFICATE is 
used, this error message is given. The documentation says:

MHD_OPTION_HTTPS_CRED_TYPE
Daemon credentials type. Either certificate or anonymous, this option should be 
followed by one of the values listed in "enum gnutls_credentials_type_t".
Any Idea on what to do with this? Is there some other config I need to 
use/change for this to work? When I remove the "MHD_OPTION_HTTPS_CRED_TYPE" and 
"MHD_OPTION_HTTPS_PRIORITIES" , the server works (but not in the mode I need, 
obviously).

If this is simply not supported, any idea if there are any plans to ever 
support this?

Any help will be very much appreciated.

Thanks,

Tal

[http://www.cisco.com/c/dam/m/en_us/employee-connection/signaturetool/images/banners/Photography/banner7.png]



Tal Maoz
Senior Software Engineer
CTAO Innovation Group
tm...@cisco.com
Tel: +972-2-5886289

Cisco Systems Israel Ltd.
5 Shlomo Halevi Street
Har Hotzvim High Tech Park
Jerusalem
9777019
Israel
Cisco.com

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/linkedin-16x16.png]



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

Re: [libmicrohttpd] Using GnuTLS with GNUTLS_CRD_PSK and AES-256-GCM, SHA384

2018-05-22 Thread Christian Grothoff 
Dear Tal,

If you look at daemon.c:580, you can see that so far we only implemented
the CRD_CERTIFICATE type.  There is no fundamental reason why PSK could
not be supported, but the respective data structures would need to be
added to 'struct MHD_Daemon' and the case filled in here with the right
call to gnutls.

I've never used the PSK API of GnuTLS, so some (likely small) digging
might be required to figure out what exactly should be called.  Also,
another MHD_OPTION_HTTPS_PSK_KEY or something like that would likely be
needed.

I don't mind adding support, but I'm pretty busy so unless I receive a
patch (or say a donation to GNUnet e.V, too small for "real" funding)
this is unlikely to happen super-quickly.


Happy hacking!

Christian

On 05/22/2018 07:58 PM, Tal Maoz (tmaoz) wrote:
> Hey guys,
> 
>  
> 
> I hope someone can help with this as it is pretty urgent.
> 
> I’m trying to build a simple secure server over libmicrohttpd.
> 
> I compiled version 0.9.59 with libgnutls 3.5.18.
> 
> I’m trying to use TLS-PSK with AES-256-GCM and SHA384 but I get an error:
> 
> Ø  Error: invalid credentials type 4 specified.
> 
>  
> 
> My code:
> 
>  
> 
> *daemon = MHD_start_daemon(MHD_USE_THREAD_PER_CONNECTION | MHD_USE_SSL |
> MHD_USE_DEBUG,*
> 
> *   arguments.port_arg,*
> 
> *   NULL,*
> 
> *   NULL,*
> 
> *   &request_handler,*
> 
> *   NULL,*
> 
> *   MHD_OPTION_CONNECTION_TIMEOUT, 256,*
> 
> *   MHD_OPTION_HTTPS_CRED_TYPE,
> GNUTLS_CRD_PSK,*
> 
> *   MHD_OPTION_HTTPS_PRIORITIES,
> "NONE:+AES-256-GCM:+SHA384",*
> 
> *   MHD_OPTION_HTTPS_MEM_KEY, key_pem,*
> 
> *   MHD_OPTION_HTTPS_MEM_CERT, cert_pem,*
> 
> *   MHD_OPTION_END);*
> 
>  
> 
> I looked into the source code of libmicrohttps and in
> microhttpd/daemon.c:576 I see that, for some reason, if anything other
> than GNUTLS_CRD_CERTIFICATE is used, this error message is given. The
> documentation says:
> 
>  
> 
> MHD_OPTION_HTTPS_CRED_TYPE
> 
> Daemon credentials type. Either certificate or anonymous, this option
> should be followed by one of the values listed in "enum
> gnutls_credentials_type_t".
> 
> Any Idea on what to do with this? Is there some other config I need to
> use/change for this to work? When I remove the
> “*MHD_OPTION_HTTPS_CRED_TYPE*“ and “*MHD_OPTION_HTTPS_PRIORITIES*” , the
> server works (but not in the mode I need, obviously).
> 
>  
> 
> If this is simply not supported, any idea if there are any plans to ever
> support this?
> 
>  
> 
> Any help will be very much appreciated.
> 
>  
> 
> Thanks,
> 
>  
> 
> Tal
> 
>  
> 
> http://www.cisco.com/c/dam/m/en_us/employee-connection/signaturetool/images/banners/Photography/banner7.png
> 
>  
> 
>   
> 
> *Tal Maoz*
> 
> Senior Software Engineer
> 
> CTAO Innovation Group
> 
> tm...@cisco.com 
> 
> Tel: *+972-2-5886289*
> 
>   
> 
> *Cisco Systems Israel Ltd.*
> 
> 5 Shlomo Halevi Street
> 
> Har Hotzvim High Tech Park
> 
> Jerusalem
> 
> 9777019
> 
> Israel
> 
> Cisco.com 
> 
>   
> 
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/linkedin-16x16.png
> 
> 
>  
> 
> http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif Think before
> you print.
> 
>  
> 
>  
> 
>  
> 



signature.asc
Description: OpenPGP digital signature