Using SSL and the ssl context object

Marcelo Roberto Jimenez — Wed, 08 Apr 2020 13:16:17 -0000

Hi John,

Lets continue in github, the current collaborating people are mostly there now.

Regards,
Marcelo.

Using SSL and the ssl context object

John Smith — Wed, 08 Apr 2020 11:43:49 -0000

Hi,
I have a question about how OpenSSL works in libupnp. There is only 1 function, "UpnpInitSslContext()" that just enables it. If you pass it a "1", then libupnp will initialize the SSL context object "gSslCtx". If you pass in a "0", then the developer is responsible for creating the SSL context object.

Are we now able to use "https://" instead of "http://" in our requests?

There is a missing component, which is how to access the SSL context object within libupnp so that the developer can configure it. Below are 2 situations where a developer would need to get/set the SSL context object "gSslCtx".

1) If I let libupnp create the SSL context and initialize SSL, how can I tell the SSL object to use my certificate and keyfile for validation?
2) If I create the SSL context, initialize SSL, and configure it with my certificate/keyfile, how do I pass this object to libupnp so that it can use it?

Or am I not understanding the use of SSL in libupnp? I have already created an issue in GitHub #169.

Thanks,
John

Compile error in list.h using libupnp 1.8.4

Marcelo Roberto Jimenez — Sat, 04 Apr 2020 20:37:49 -0000

Hi John,

Please open a new issue here: https://github.com/pupnp/pupnp/issues

I am a bit confused, would you have a suggestion patch so that we can analyze?

Please answer in github.

Regards,
Marcelo.

Compile error in list.h using libupnp 1.8.4

John Smith — Fri, 03 Apr 2020 21:50:07 -0000

Hi, I have an app that links to libupnp v1.8.4 that is compiled on ATOM processor. I get the following error:
list.h:177:35: error: 'UL' undeclared (first use in this function)
entry->next = (struct list_head)LISTPOISON1;
After sever days of debugging, it turns out there was a problem in poison.h where POISON_POINTER_DELTA is defined as AC(CONFIGILLEGALPOINTERVALUE, UL) because CONFIG_ILLEGAL_POINTER_VALUE is defined.

When libupnp is compiled, CONFIG_ILLEGAL_POINTER_VALUE is not defined. But my app has it defined and one of my .c files includes upnp.h, which then generates the above error. I added "#include <linux const.h="">" in the poison.h file and both libupnp and my library seems to build fine.</linux>

My app uses bitbake to build and we have an automated build system for our daily builds. This means that libupnp is fetched and built. Can this problem be patched so that I can include it in my build system?

openssl link errors

Rémi Carrier — Sat, 12 Oct 2019 16:05:14 -0000

For me, adding the following to LDFLAGS worked:

LDFLAGS="-L/usr/lib -lssl -lcrypto -lz"

The make check doesn't report any failure. and the resulting libupnp.so reports the following:

ldd /usr/lib/libupnp.so
        linux-vdso.so.1 (0x00007ffff07c5000)
        libixml.so.10 => /usr/lib/libixml.so.10 (0x00007f5746afe000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f5746a69000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007f5746785000)
        libz.so.1 => /lib/libz.so.1 (0x00007f5746768000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5746747000)
        libc.so.6 => /lib/libc.so.6 (0x00007f5746583000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f574657c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5746b67000)

I haven't tested on ARM, but on AMD64 this seems to be okay.

openssl link errors

Rick Lesniak — Thu, 08 Aug 2019 20:28:09 -0000

Trying to build upnp with --enable-open_ssl. I have openssl-1.1.1c installed, but the upnp makefile is having problems linking. Same issue on ubuntu and raspbian

/bin/bash ../../libtool  --tag=CC   --mode=link gcc  -pthread -g -O2 -Os -Wall   -o unittest unittest-main.o templates/unittest-FirstObject.o templates/unittest-templates.o templates/unittest-SecondObject.o ../../upnp/libupnp.la ../../ixml/libixml.la 
libtool: link: gcc -pthread -g -O2 -Os -Wall -o .libs/unittest unittest-main.o templates/unittest-FirstObject.o templates/unittest-templates.o templates/unittest-SecondObject.o  ../../upnp/.libs/libupnp.so /home/pi/libupnp-1.8.4/ixml/.libs/libixml.so ../../ixml/.libs/libixml.so -pthread
../../upnp/.libs/libupnp.so: undefined reference to `SSL_write'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_free'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_set_fd'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_read'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_new'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_shutdown'
../../upnp/.libs/libupnp.so: undefined reference to `OPENSSL_init_crypto'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_CTX_new'
../../upnp/.libs/libupnp.so: undefined reference to `OPENSSL_init_ssl'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_connect'
../../upnp/.libs/libupnp.so: undefined reference to `SSL_CTX_free'
collect2: error: ld returned 1 exit status
Makefile:397: recipe for target 'unittest' failed
make[3]: *** [unittest] Error 1
make[3]: Leaving directory '/home/pi/libupnp-1.8.4/upnp/unittest'
Makefile:1648: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/pi/libupnp-1.8.4/upnp'
Makefile:498: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/pi/libupnp-1.8.4'
Makefile:399: recipe for target 'all' failed
make: *** [all] Error 2
pi@CM3:~/libupnp-1.8.4$

How can I disable logging (3GB+ log files being created)

Tue, 05 Apr 2016 20:41:56 -0000

The log files can grow to rediclous proportions and are unnecessary in my implementation. Is there any way to disable logging altogether?

libupnp double free bug

Marcelo Roberto Jimenez — Fri, 08 Jan 2016 15:45:01 -0000

Hi Jean-Francois,

You are correct, I failed to recognize the pattern. I will revert it asap.

Regards,
Marcelo.

libupnp double free bug

Jean-Francois Dockes — Fri, 08 Jan 2016 09:12:54 -0000

Hi,

I saw the commit subsequent to this discussion, and it looks suspicious to me.

The ct count serves as a shared reference count for the object. When it goes to zero, the object is released. At this point, nobody else should be holding a reference to the object (else the count would be > 0). So having an additional alias_release() is the bug,

Having a shared counter is what allows doing a shallow copy of the object in webserver.c:alias_grab(). alias_grab() could be called on any copy of the object, and still maintain the counter properly, so that the shared memory buffer pointed to by the doc field is also properly managed.

It's the same mechanism used by std::shared_ptr(). Read a description of this if you want a more authorized one. Of course C++ has the benefit of automated maintenance of the ref count because of the triggering of constructors/destructors.

Turning ct into a local int instead of a shared value removes the purpose of this counter.

As far as I can see, the new code does not make much sense. Example:

after web_server_set_alias() is called, gAliasDoc has ct==1
Someone calls alias_grab(). Their copy has ct == 2 but gAliasDoc.ct is still 1 !
web_server_set_alias() is called again. gAliasDoc becomes 0, the doc is destroyed, but the caller of alias_grab() still has a reference to it, and this could then cause an invalid memory access.

In the general case, memory leaks would also be possible, but probably not here as aliases are always a copy of gAliasDoc, not of an arbitrary copy. The ct of gAliasDoc is never incremented, so the issue will always be an early release of the resources.

My suggestion would be to revert this change, which at the very minimum goes against the intention of the initial coder, and check the pairing of alias_grab()/alias_release() calls instead. And the thing which is missing as Nick noted, is a test case demonstrating that there is actually a problem.

libupnp double free bug

Marcelo Roberto Jimenez — Thu, 07 Jan 2016 21:05:01 -0000

Homerzhou,

Perfect observation. I will commit a patch, please test it and report.

Regards,
Marcelo.

Recent posts to Discussion

Using SSL and the ssl context object

Using SSL and the ssl context object

Compile error in list.h using libupnp 1.8.4

Compile error in list.h using libupnp 1.8.4

openssl link errors

openssl link errors

How can I disable logging (3GB+ log files being created)

libupnp double free bug

libupnp double free bug

libupnp double free bug