Hi, I've hit a few problems with openl2tp-1.8 and the hide_avps option.
The first problem comes from the AVP hiding routine.
In order to set the hidden AVP subformat (i.e. prepend the original
buffer with a two bytes length field), the l2tp_avp_hide() function
(in l2tp_avp.c) re-allocates 'orig_buffer' and shifts its memory
content two bytes forward. The problem is that 'orig_buffer' is used
as base address for memmove() after a successful realloc(orig_buffer, ...)
call (in which case 'orig_buffer' becomes an invalid pointer). The
'new_buffer' variable should be used instead:
new_buffer = realloc(orig_buffer, new_buffer_len + L2TP_AVP_HEADER_LEN);
if (new_buffer == NULL) {
return -ENOMEM;
}
- memmove(new_buffer + L2TP_AVP_HEADER_LEN + 2, orig_buffer +
L2TP_AVP_HEADER_LEN, orig_buffer_len - L2TP_AVP_HEADER_LEN);
+ memmove(new_buffer + L2TP_AVP_HEADER_LEN + 2, new_buffer +
L2TP_AVP_HEADER_LEN, orig_buffer_len - L2TP_AVP_HEADER_LEN);
The current implementation randonly fails to unhide AVPs when
new_buffer != orig_buffer.
A second problem lies in the AVP unhiding routine. The same function is
called for hiding and unhiding: l2tp_avp_hide_unhide() in l2tp_avp.c.
Even though the 'hide' parameter is used to indicate whether hiding or
unhiding is requested, the same algorithm is used in both cases:
-the first 16 bytes block is xor-ed with MD5(message_type, secret,
random_vector)
-each remaining 16 bytes block is xor-ed with MD5(secret, previous_block)
Since blocks are treated left to right, applying this algorithm on
clear text AVPs results in xor-ing each block (but the first one) with
MD5(secret, previous_hidden_block), which is fine in regard
to RFC 2661 section 4.3.
But when applied to hidden attributes these blocks get xor-ed with
MD5(secret, previous_unhidden_block). The first block is normally
decoded however, as it only depends on message_type, secret and
random_vector.
So unhidden attributes get their first 16 bytes properly decoded while
having the rest garbled. E.g. an unhidden Vendor Name AVP will have its
first 14 bytes properly decoded (as two bytes are used for storing the
original AVP length) and the rest gets unreadable. For Challenge AVPs
bigger than 14 bytes, incorrect unhiding prevents authentication to the
peer.
This problem can be fixed by handling blocks right to left when
unhiding attributes.
Best regards,
--
Guillaume Nault
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________ Openl2tp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openl2tp-users
