I tried removing the [[OpenBSD]] prelude packages and compile prelude + ossec from source.
now I get the following error from prelude when ossec tries to connect to prelude-manager :
"Ohhhh jeeee: operation is not possible without initialized secure memory"

after installing from source I now get the "Ohhhh jeeee: operation is not possible without initialized secure memory" with other sensors too (prelude-lml, snort).

I tried doing a clean installation but got the same error.

versions are :

gnutls - 2.5.2
libgcrypt - 1.4.1
libgpg-error - 1.6
libprelude - 0.9.17.2
prelude-manager - 0.9.13

Hi,

Prior to getting the

Ohhhh jeeee: operation is not possible without initialized secure memory

error message, what software versions where you using?

Replying to [comment:3 yoann]:

Hi,

Prior to getting the

> Ohhhh jeeee: operation is not possible without initialized secure memory

error message, what software versions where you using?

Hello Yoann,

I was first using the 4.3 [[OpenBSD]] packages : libprelude-0.9.15,prelude-manager-0.9.9,gnutls 2.0.4
and had no problem with snort/prelude-lml sensors. problem started with OSSEC (TLS ERROR), so i
tried reinstalling and since it did not work I downloaded prelude source, installed it and since then i always
get the "secure memory" error when a sensor tries to connect to prelude-manager (registration works fine).

Thanks

I reinstalled openbsd 4.3 from scratch, first thing after the installation i compiled latest gnutls 2.52,libgcrypt - 1.41 libgpg-error - 1.6
and then installed libprelude-0.9.17.2, prelude-manager-0.9.13 from source.

I still get the "secure memory" error when a sensor connects with prelude-manager...

created another 4.3 clean installation under vmware server, compiled current versions from source , this time using gnutls 2.0.4 from openbsd 4.3 package - error is again "TLS error: A TLS packet with unexpected length was received".

[[GnuTLS]] 2.5.x is development version: you probably should avoid it. I'd suggest sticking to [[GnuTLS]] 2.0.4.
To summarize, can you confirm that you are back to the following issue:

• Starting OSSEC lead to unexpected length error on the Prelude-Manager side
  • What about the OSSEC side, what does it tell?
• Prelude-LML and Snort, located on the same machine as OSSEC, are working.

Can you confirm this?

Additionally, please provide the output from the following command, both on the OSSEC and Prelude-Manager machine:

prelude-admin list -l

just to make clear : I run all sensors (ossec server,snort,prelude-lml) on the same machine as prelude.

summary of behavior with gnutls 2.0.4 & default openbsd 4.3 packages of prelude.

1. ossec reponse when communicating with prelude-manager is "ossec-analysisd :prelude-client: Unable to initialize prelude client: TLS handshake failed: Could not negotiate a supported compression method.."

2. prelude-manager side says: "TLS error: A TLS packet with unexpected length was received" and then prelude-manager closes the connection.

3. i can confirm prelude-lml & snort working, both were installed prior to ossec.

I will run the prelude-admin command tomorrow (when ill be in front of the computer) and provide the input.

Thanks for your help!

prelude-admin list -l output:

Profile UID GID [[AnalyzerID]] Permission Issuer [[AnalyzerID]]
---------------------------------------------------------------------
prelude-manager root wheel 556568847730105 n/a n/a
OSSEC ossec ossec 3784451519039096 idmef:w 556568847730105
prelude-lml root wheel 2102602455468194 idmef:w 556568847730105

tried even again just to make sure :
installed openbsd 4.3, prelude from openbsd port, ossec from source. TLS error (unexpected length) again...
prelude-lml works fine though.

Could you try starting OSSEC using either of the working Snort / Prelude-LML profile (you will have to use prelude-admin chown to make sure the profile fit OSSEC permissions).

Edit ossec.conf, and set:

<prelude_profile>your profile</prelude_profile>

Hi Yoann,

1. I still get the same error after replacing OSSEC profile to prelude-lml.
2. I successfully installed latest prelude (from source, not openbsd package) + latest ossec on the same machine with gnutls-2.4.0.

Thanks for the feedback! I'm suspecting a potential conflict problem between [[GnuTLS]] (which depend on libz), and OSSEC which seems to make use of it to.

One more things you can do to debug the problem, is to start both OSSEC and Prelude-Manager in the foreground with the following environment variable set:

LIBPRELUDE_TLS_DEBUG=10 prelude-manager >& /tmp/prelude-manager.debug

LIBPRELUDE_TLS_DEBUG=10 ossec >& /tmp/ossec.debug

Then provide us with both generated file (I'd advise to regenerate all your sensor profile once you'll be doing that, since the debug log might contain sensitive certificate information - or you can send me the log by mail privately).

Additionally, is the Prelude-Manager side [[GnuTLS]] version 2.0.4 too?

Hey Yoann,

1. I attached the 2 debug files from ossec+prelude-manager.
2. prelude-manager + ossec server both installed on same machine so both use gnutls 2.0.4
3. Applying the patch to manager-auth.c did not help solve the problem (still the same error), but I could not find
the error message you added to manager-auth.c in the diff file...

i checked the value of ret after the line : ret = gnutls_init(&session, GNUTLS_SERVER);
value is 0 (=GNUTLS_E_SUCCESS) so initialization of the TLS session is successful.

Thanks for the feedback.
Attached another patch for libprelude : libprelude.diff, please apply and restart both Prelude-Manager then OSSEC.

Additionally, could you please provide the "ldd" output for libgnutls.so, and check whether zlib is linked, on both the client and server side?

Replying to [comment:16 anonymous]:

i checked the value of ret after the line : ret = gnutls_init(&session, GNUTLS_SERVER);
value is 0 (=GNUTLS_E_SUCCESS) so initialization of the TLS session is successful.

Yes, that is expected: the problem occur within gnutls_handshake(), where both client and server are not able to negotiate a compatible compression scheme (or no compression scheme at all. Which should obviously work).

1. ldd /usr/local/lib/libgnutls.so.13.0 : linked with libz.so.4.1 (same machine)

2. applying the libprelude patch solved the problem.

thanks for all the help!

(BTW, dont know if you saw the message but i got it working yesterday with gnutls 2.4.0. so it works without the patch with 2.4.0 but patch is required for 2.0.4 & 2.5.2 - these are the versions i tested)

Look like we're finally getting somewhere! There is one more clarification that we need in order to fixes the problem directly from the Prelude sources: does libprelude.diff fixes the problem with and without manager.diff applied?

I uninstalled prelude-manager & installed the version from source again (without the patch) - authentication with ossec succeeded.
so the fix in libprelude module is sufficient to solve this problem.

Thanks! In the modified libprelude source, could you locate the following line:

        const int c_prio[] = { GNUTLS_COMP_NULL, GNUTLS_COMP_DEFLATE, 0 }; 

And change it to:

        const int c_prio[] = { GNUTLS_COMP_NULL, 0 }; 

And tell me whether everything still work correctly?

works fine after the change.
so you basically disable protocol compression or fallback to no compression if handshake fails?

The workaround explicitly disable TLS deflate compression in the client. [[GnuTLS]] default settings is that deflate is not used, but for some reason, in your case, it seems to be marked as the default compression method, leading to a failure since Prelude-Manager is not configured to support it. I guess this probably have to do with the OSSEC zlib dependency.

By any chance, are you able to reproduce #300 on your [[OpenBSD]] platform?

Replying to [comment:24 yoann]:

The workaround explicitly disable TLS deflate compression in the client. [[GnuTLS]] default settings is that deflate is not used, but for some reason, in your case, it seems to be marked as the default compression method, leading to a failure since Prelude-Manager is not configured to support it. I guess this probably have to do with the OSSEC zlib dependency.

By any chance, are you able to reproduce #300 on your [[OpenBSD]] platform?

yes, it was me who opened it...sorry i didn't have the time to upload the files requested, I was busy with #299 :)
I will add the files soon.