IPv6 Fails to Compile

[jacob-baines]

System: Ubuntu 12.10 32 bit using libnet version 1.1.4

When IPv6 is enabled Ettercap fails to compile due to undeclared variables. A bunch of these values are defined in netinet/icmp6.h. Also, it appears that some of the values used to be defined in earlier versions of libnet/libnet-headers.h but the values were changed or removed? Finally, some of the definitions have the correct values in ec_proto.h but the wrong name (ie. ICMP6_ECHO is defined in ec_proto.h but ettercap uses ICMP6_ECHO_REQUEST in ec_send.c).

[ 19%] Building C object src/CMakeFiles/ettercap.dir/ec_send.c.o
/ettercap/src/ec_send.c: In function ‘send_icmp6_echo’:
/ettercap/src/ec_send.c:647:33: error: ‘ICMP6_ECHO_REQUEST’ undeclared (first use in this function)
/ettercap/src/ec_send.c:647:33: note: each undeclared identifier is reported only once for each function it appears in
/ettercap/src/ec_send.c: In function ‘send_icmp6_nsol’:
/ettercap/src/ec_send.c:702:39: error: ‘ND_OPT_SOURCE_LINKADDR’ undeclared (first use in this function)
/ettercap/src/ec_send.c:709:12: error: ‘LIBNET_ICMPV6_NDP_OPT_H’ undeclared (first use in this function)
/ettercap/src/ec_send.c:712:37: error: ‘ND_NEIGHBOR_SOLICIT’ undeclared (first use in this function)
/ettercap/src/ec_send.c:722:9: error: ‘LIBNET_ICMPV6_NDP_NSOL_H’ undeclared (first use in this function)
/ettercap/src/ec_send.c: In function ‘send_icmp6_nadv’:
/ettercap/src/ec_send.c:761:36: error: ‘ND_OPT_TARGET_LINKADDR’ undeclared (first use in this function)
/ettercap/src/ec_send.c:767:9: error: ‘LIBNET_ICMPV6_NDP_OPT_H’ undeclared (first use in this function)
/ettercap/src/ec_send.c:769:12: error: ‘ND_NA_FLAG_SOLICITED’ undeclared (first use in this function)
/ettercap/src/ec_send.c:769:33: error: ‘ND_NA_FLAG_OVERRIDE’ undeclared (first use in this function)
/ettercap/src/ec_send.c:771:16: error: ‘ND_NA_FLAG_ROUTER’ undeclared (first use in this function)
/ettercap/src/ec_send.c:772:37: error: ‘ND_NEIGHBOR_ADVERT’ undeclared (first use in this function)
/ettercap/src/ec_send.c:783:9: error: ‘LIBNET_ICMPV6_NDP_NADV_H’ undeclared (first use in this function)

[LocutusOfBorg]

Could you please try to build libnet 1.1.6 and build again?

I think I remember that libnet 1.1.4 doesn't build correctly so we disabled ipv6 until 1.1.6 hits debian/ubuntu.

The debian mantainer of libnet is aware of this

[jacob-baines]

You are correct. Everything compiles with 1.1.6 installed.

[LocutusOfBorg]

Ettercap is available with ipv6 enabled in my ppa, with the new libnet too (from debian experimental)
https://code.launchpad.net/~costamagnagianfranco/+archive/ettercap-stable-backports

[eaescob]

Can this issue be closed?

[jacob-baines]

I would say that is up to you guys. The original issue still stands. There appears to be no documentation / indication to a developer using a Debian distro that they need to use libnet 1.1.6 or above.

Ideally, specifying a minimum version in CMake would be great, but I couldn't seem to make that work. Perhaps somewhere in the install documentation a note should be dropped? I'm happy to write the proper blurb if someone points me to the correct location.

[eaescob]

@jacob-baines Good point on requiring at least 1.1.6, perhaps what I can add is some logic to CMake to determine whether 1.1.6 was not found and IPv6 is enabled and print out a warning message.

[eaescob]

@jacob-baines Thanks for the contribution!

[eaescob]

Submitted pull request for #104 this should error out if IPV6 is enabled and libnet 1.1.5 (or higher) was not found.

[justfalter]

Any reason we can't simply bundle libnet with Ettercap? By extension, we could do the same for libpcap, libpcre, and others.

Nmap actually bundles libnet, lua, liblinear, libpcap, AND libpcre with its distribution. When configuring the build, one can specify '--with-libdnet=included'. If they want to use a user/distro-specified lib, they could provide '--with-libdnet=/usr/local/bla/bla/bla'.

I used cmake's ExternalProject command to bundle luajit with my lua build of ettercap here. It worked really well, and I'll be very happy to spend some time bundling all the stuff that Ettercap is dependent upon.

Proposal:

• Bundle external libs, where possible (libnet, libpcre, libpcap, etc). This should be reasonable (don't include GTK2 or Curses, for example :))
• Provide ability to use user/distro-provided libs, if so desired.
• Allow for the disabling of functionality that has lib-specific requirements (a la ENABLE_IPV6)

This would mean that the Debian distro (as well as users) would have the following choices:

1. Use our included version of libnet (LIBNET_PATH=included) and have IPV6 support (ENABLE_IPV6=On)
2. Upgrade their version of libnet (LIBNET_PATH=/usr/local) and have IPV6 support (ENABLE_IPV6=On)
3. Disable IPV6 support (ENABLE_IPV6=Off)

Here are the pros/cons:
PROS:

1. Ettercap becomes significantly easier to install, given that we would have reduced its explicit dependance upon user/distro-installed libraries.
2. Ettercap users are provided with a much more consistent experience if they were to use our libs-included build.
3. When implemented properly, users/distros will be able to specify that they would like to use their own builds of libnet, libpcap,

CONS:

1. Larger source-code footprint since it'd mean including tarballs for external libs.
2. Larger installation footprint since we'd be potentially statically linking external libs into ettercap.

[eaescob]

Considering the amount of "issues" reported dealing with wrong versions of libnet, I would suggest to go ahead and work on this. I like the idea, thanks!

[LocutusOfBorg]

Cons: libraries are usually HARD customized for linux distros, I don't like this approach.

I could like it only if it is disabled by default.

[justfalter]

First, a correction: nmap bundles libdnet, not libnet. My bad.

@LocutusOfBorg What I'm proposing explicitly requires that distros/users are able to specify their own builds of libraries. We aren't dictating anything; the choice as to whether they would use the included libs (or not) is entirely up to the user/packager.

To be clear:

1. We would make it easy for packagers to override 'included' libraries with their own via build-time configuration options.
2. We would also do our best to make it possible to enable/disable features that maybe require newer versions of a library, if that makes it easier for packagers to do their thing.

I want users on Distros like Debian-stable to be able to attack IPV6 without having to jump through a bunch of hoops. Remember: they'll come to us asking why they are getting build-errors, not the Debian folks.

Ettercap isn't a normal application. It's a security tool. Let's follow in Nmap's footsteps and make it super easy to build.

[LocutusOfBorg]

@justfalter You were clear enough, don't worry!
The problem is that e.g. nowadays I'm debugging a network tool that uses a locally patched version of one library (libpcap i think), I try to debug, to package a patched version and so on, and after all I see that I'm wasting my time because the program uses another program that has an embedded copy off libpcap, so you need to patch the embedded one and not the packaged one.
So my point is that the packaging system has been created to look, keep the system and the dependencies aligned with the system, and the customizations too, and to make easier to backport patches as well.

Another point: ettercap is a security tool (you said).

Let us assume libnet has a CVE.
Linux mantainers fix it and backport the patch.

ETTERCAP WILL STILL BE VULNERABLE.

Another point, we will need to take care of updating them every time a new version comes out, or to patch them.

My point is: good to give this possibility, but the DEFAULT should be to use the shared library, and to move to our customization in a future (maybe after more than one year of testing)
Libnet and curl can be embedded anytime for the benefits of embedding them.

Just my .02$

[LocutusOfBorg]

I'm not complaining, I just want to give a point of view that a security tool mantainer should be aware of.

[justfalter]

@LocutusOfBorg All of those are totally fair points that I agree with. Let's continue the discussion when I submit a pull for the libnet stuff. I want to make sure that you and I have something that we can agree upon. I agree on defaulting to system shared libs.

At the end of this, it is vital that we produce good documentation that clearly explains the build options along with their impacts.

Oh, by the way, should we be closing this issue? I feel like I've hijacked things.

[LocutusOfBorg]

For me the point is already clear, I agree with you and you with me, we do not differ in thoughts, I was just saying something you maybe missed on your first post. :)

I agree with the pull request, I'm pretty sure the developers will like this too.

[eaescob]

Can we close this issue? :)