This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.
Differences between revisions 3 and 4
Revision 3 as of 2006-03-08 02:19:32
Size: 2272
Editor: 58
Comment:
Revision 4 as of 2006-06-05 03:19:13
Size: 2276
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
== Canary and Guard Pages in Ethereal == == Canary and Guard Pages in Wireshark ==
Line 4: Line 4:
In order to help detect memory over- and under-flows in ([http://wiki.ethereal.com/EMEMification se_ and ep_]) allocated memory, Ethereal now places canary values (e.g., a gap or no-mans-land) after each allocation. When the memory is later freed, the canary values are checked to make sure that they haven't been changed. If they have, then someone has written past the memory that they allocated. See also [http://gcc.fyxm.net/summit/2003/Stackguard.pdf stackguard]. In order to help detect memory over- and under-flows in ([http://wiki.wireshark.org/EMEMification se_ and ep_]) allocated memory, Wireshark now places canary values (e.g., a gap or no-mans-land) after each allocation. When the memory is later freed, the canary values are checked to make sure that they haven't been changed. If they have, then someone has written past the memory that they allocated. See also [http://gcc.fyxm.net/summit/2003/Stackguard.pdf stackguard].
Line 6: Line 6:
In addition, guard pages are placed before and after each block of memory. These are entire pages of memory that are mprotect()'d against writes so that if the page is written to (because someone went '''way''' beyond the end of their allocated memory), Ethereal will get a memory access violation (and hopefully dump core for post-mortem analysis). In addition, guard pages are placed before and after each block of memory. These are entire pages of memory that are mprotect()'d against writes so that if the page is written to (because someone went '''way''' beyond the end of their allocated memory), Wireshark will get a memory access violation (and hopefully dump core for post-mortem analysis).
Line 19: Line 19:
=== What should I do if Ethereal detects such a canary violation? === === What should I do if Wireshark detects such a canary violation? ===
Line 21: Line 21:
If Ethereal exits stating "Per-packet memory corrupted." and exits (possibly leaving a core file (on *NIX, anyway) that points to epan/emem.c around line 600), then Ethereal detected a canary violation. If you're not a developer, you're not compiling Ethereal yourself, or you don't have the time to debug the issue yourself, please [http://bugs.ethereal.com open a bug] and attach a (preferrably small) capture file that exhibits the problem. If Wireshark exits stating "Per-packet memory corrupted." and exits (possibly leaving a core file (on *NIX, anyway) that points to epan/emem.c around line 600), then Wireshark detected a canary violation. If you're not a developer, you're not compiling Wireshark yourself, or you don't have the time to debug the issue yourself, please [http://bugs.wireshark.org open a bug] and attach a (preferrably small) capture file that exhibits the problem.
Line 27: Line 27:
 * run ethereal/tethereal under [http://www.valgrind.org Valgrind]  * run wireshark/tshark under [http://www.valgrind.org Valgrind]
Line 29: Line 29:
     * valgrind .libs/lt-tethereal -Vnxr /some/file > /dev/null 2> valgrind.out      * valgrind .libs/lt-tshark -Vnxr /some/file > /dev/null 2> valgrind.out

Canary and Guard Pages in Wireshark

In order to help detect memory over- and under-flows in ([http://wiki.wireshark.org/EMEMification se_ and ep_]) allocated memory, Wireshark now places canary values (e.g., a gap or no-mans-land) after each allocation. When the memory is later freed, the canary values are checked to make sure that they haven't been changed. If they have, then someone has written past the memory that they allocated. See also [http://gcc.fyxm.net/summit/2003/Stackguard.pdf stackguard].

In addition, guard pages are placed before and after each block of memory. These are entire pages of memory that are mprotect()'d against writes so that if the page is written to (because someone went way beyond the end of their allocated memory), Wireshark will get a memory access violation (and hopefully dump core for post-mortem analysis).

With the guard pages in place, memory allocations now look like:

  +----+--------+---+--------+---+--------+---+-------+----+
  | gp | alloc1 | c | alloc2 | c | alloc3 | c |  ...  | gp |
  +----+--------+---+--------+---+--------+---+-------+----+

("gp" = guard page, "allocn" = allocated memory, "c" = canary).

What should I do if Wireshark detects such a canary violation?

If Wireshark exits stating "Per-packet memory corrupted." and exits (possibly leaving a core file (on *NIX, anyway) that points to epan/emem.c around line 600), then Wireshark detected a canary violation. If you're not a developer, you're not compiling Wireshark yourself, or you don't have the time to debug the issue yourself, please [http://bugs.wireshark.org open a bug] and attach a (preferrably small) capture file that exhibits the problem.

If you can debug the issue yourself, the best thing to do (again, on Linux, anyway) is to:

  • first update your source to see if the bug has already been fixed :-)

  • in epan/emem.c, uncomment the #defines of EP_DEBUG_FREE and SE_DEBUG_FREE
  • recompile
  • run wireshark/tshark under [http://www.valgrind.org Valgrind]

    • unless you did a make install (to get the libtool stuff out of the way), this probably means doing something like:
      • valgrind .libs/lt-tshark -Vnxr /some/file > /dev/null 2> valgrind.out

Development/Canary (last edited 2008-09-25 13:19:42 by JeffMorriss)