Eventhough it appears the fuzztesting and the value_string termination audit and the str...() replacement tasks seems to have been very successful
(i feel a major decrease in number of vulnerabilities and issues compared to 6 months ago)
it would not hurt to add more.
I am in full support of adding extra emem checking, GP or other implementations.
But instead of MMU tricks to trigger SEGV, would it not be sufficient (and simpler) to add a "canary" value prior to the allocation as well, then have the canary values build a linked list of head/tail canaries. A list that can occasionally (and when the list is destroyed/released) be walked to verify that the pointers and the canary values look sane.
Lets add a canary to just prior to the allocated memory also instead of just at the tail of the allocated memory.
It might be simpler to implement than MMU tricks and SIGSEGV.
I think that when a canary is found to be corrupted this is evidence of memory corruption and then it is perfectly valid to abort immediately.
--snip--
c: Canary values placed after each memory allocation.
empty: Unallocated (empty) space.
The canary values can be used to detect buffer overflows, but not
prevent them. Would it be useful to add guard pages before and after
each block of memory, e.g.
+----+--------+---+--------+---+--------+---+-------+----+
| gp | alloc1 | c | alloc2 | c | alloc3 | c | empty | gp |
+----+--------+---+--------+---+--------+---+-------+----+
The guard pages could be protected using mprotect(), which would trigger
a segmentation fault any time the gp memory was accessed.
Would the guard pages be useful, or are the canary values alone
sufficient for our needs?
Also, how can we more gracefully handle instances where the canary
values are overwritten? Right now we just abort.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxxhttp://www.ethereal.com/mailman/listinfo/ethereal-dev