Bug 832698 - Review Request: CERT Triage tools - a gdb extension similar to microsoft's !exploitable
Summary: Review Request: CERT Triage tools - a gdb extension similar to microsoft's !e...
Keywords:
Status: CLOSED DUPLICATE of bug 1472405
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-16 16:59 UTC by Josh Bressers
Modified: 2023-09-14 01:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-28 18:30:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Josh Bressers 2012-06-16 16:59:59 UTC
Spec URL: http://fedorapeople.org/~bressers/exploitable-review/exploitable.spec
SRPM URL: http://fedorapeople.org/~bressers/exploitable-review/exploitable-1.01-1.fc16.src.rpm
Description: CERT Triage tools, which currently only contain a gdb extension called exploitable
Fedora Account System Username: bressers


I've packaged up CERT's Triage tools, which are really just a gdb extension right now. The package installs an extension specific python module, and a script into /usr/bin

The script doesn't currently have a man page (it's on my list). I wanted to start the review now as I'm certain this will need some work.

The extension basically will show the user if their application crash is exploitable or not (it's certainly not perfect, but getting this to a wider audience should help improve it greatly).

For example:

bress@localhost ~ % cert-triage /tmp/test

warning: Current output protocol does not support redirection


Description: Access violation near NULL on destination operand
Short description: DestAvNearNull (14/21)
Hash: f7ba00781cd7cb6b8ae2fbf50d65e661.f7ba00781cd7cb6b8ae2fbf50d65e661
Exploitability Classification: PROBABLY_EXPLOITABLE
Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control write address and/or value. However, it there is a chance it could be a NULL dereference.
Other tags: AccessViolation (20/21)


Additionally this can be run directly from gdb via the 'exploitable' command.

Thanks.

Comment 1 Karel Klíč 2012-09-27 13:11:16 UTC
I feel the license might be an issue.

I interpret the license of this package (file LICENSE.txt) as "BSD with advertising" because of the following section:

--
3. All advertising materials for third-party software mentioning 
   features or use of this software must display the following 
   disclaimer:

   "Neither Carnegie Mellon University nor its Software Engineering 
    Institute have reviewed or endorsed this software"
--

http://fedoraproject.org/wiki/Licensing:Main indicates that the "BSD with advertising" license is free but _incompatible with GPLv3_, which is the license of GDB including its Python interface.  The package is built on the top of that GDB Python interface.

Do you agree with this interpretation?

Comment 2 Josh Bressers 2012-09-27 13:19:49 UTC
Richard Fontana looked at this, here is his response:

Based on the information provided about the technical context I do not believe there is a licensing conflict, despite the fact that the CMU license is GPL-incompatible under orthodox understanding. The fact that the license of GDB allows for cure opportunities, and the likelihood that we could obtain a special permission from the FSF should they consider there to be a problem, has influenced my thinking on this.

Therefore, packaging of the triage tools in Fedora can proceed.

Comment 3 Karel Klíč 2012-09-27 14:30:01 UTC
I found a couple of minor issues.  Fixing them would make the package better.

1. The spec file should not include the %clean section with "rm -rf %{buildroot}".

2. There should be no "rm -rf  %{buildroot}" at the beginning of the %install section.

3. "%defattr(-,root,root,-)" should not be included at the beginning of the %files section.

4. Rpmlint warnings should be fixed

rpmlint exploitable-1.01-1.fc19.noarch.rpm

exploitable.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/exploitable-1.01/README.txt
exploitable.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/exploitable-1.01/AUTHORS.txt
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Perhaps the following link helps?
http://fedoraproject.org/wiki/Packaging_tricks#Remove_DOS_line_endings

5. AUTHORS.txt and README.txt from /usr/share/triage-tools should be installed in %doc (/usr/share/doc/exploitable-1.01/).

6. LICENSE.txt should be included in %doc files.



I have also tested the package on RHEL-6.  The GDB command works only after importing it manually:

(gdb) exploitable
Undefined command: "exploitable".  Try "help".
(gdb) require command exploitable_gdb
(gdb) exploitable
Description: Heap error
Short description: HeapError (9/21)
Hash: 6687658ff11fd9da15c43c9e6f5259bd.6687658ff11fd9da15c43c9e6f5259bd
Exploitability Classification: EXPLOITABLE
...



The cert-triage command line tool doesn't work as it cannot find the "exploitable" GDB command:

$ cert-triage ./testBranchAv.test 
Undefined command: "exploitable".  Try "help".
/usr/bin/cert-triage:152: UserWarning: triage failed ([Errno 2] No such file or directory: '/tmp/triage.pkl'), call=gdb --batch -ex "source exploitable/exploitable-gdb.py" -ex run -ex "exploitable -p /tmp/triage.pkl" --args ./testBranchAv.test
  warnings.warn("triage failed (%s), call=%s" % (e, call))

Failed to triage (no crash?): ./testBranchAv.test


Are you going to include the package in EPEL6?
If it is not so, I can test it later today on my Fedora 17 machine at home.

Comment 4 Josh Bressers 2012-09-27 18:13:36 UTC
OK, so this isn't going to work on RHEL6 as is. I spoke with the RHEL6 gdb maintainer. The ability to auto-load commands doesn't exist there. I'm going to think about how to best address that. For now let's target Fedora with plans to include this in EPEL6 eventually.

I've updated the package and spec file addressing the concerns
http://fedorapeople.org/~bressers/exploitable-review/

bress@rh rpmbuild % rpmlint RPMS/noarch/exploitable-1.01-2.fc16.noarch.rpm
exploitable.noarch: W: no-manual-page-for-binary cert-triage
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

bress@rh rpmbuild % rpmlint SRPMS/exploitable-1.01-2.fc16.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

The man page will be added in the near future.

Comment 5 Josh Bressers 2012-09-28 15:31:24 UTC
This review needs to stop. I found some GPL code in this package. I'm going to consult Fontana on what's next.

Comment 6 Mario Blättermann 2013-11-01 08:41:31 UTC
This ticket is in an odd state... Not ASSIGNED, and in fact assigned to nobody anyway, but the "fedora-review?" flag is set. I set it back, except the needinfo.

Comment 7 Christopher Meng 2013-12-28 08:53:33 UTC
Please package 1.04 when you are free.

Comment 8 Tom "spot" Callaway 2013-12-30 17:30:39 UTC
Reblocking FE-Legal, since there are legal issues (re: Comment 5)

Comment 9 Upstream Release Monitoring 2016-01-05 06:27:28 UTC
koschei's scratch build of gdb-7.10.50.20151113-33.fc24.src.rpm for f24 completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12414110

Comment 10 Tom "spot" Callaway 2018-06-13 16:07:11 UTC
The GPL licensed code was removed in a commit in 2015:
https://github.com/jfoote/exploitable/commit/f5cf8fc1dbacf6647c3a746936ead7bebd411f63

This resolves the internal licensing concerns with this code, should someone wish to take it up again. Lifting FE-Legal

Comment 11 Damian Wrobel 2018-06-28 06:50:39 UTC
Seems to be already available in Fedora since f25 [1].

[1] https://src.fedoraproject.org/rpms/gdb-exploitable

Comment 12 Jason Tibbitts 2018-06-28 18:30:39 UTC
It does seem that in the meantime this package was reviewed and accepted under the new name the developer chose after leaving CERT.

*** This bug has been marked as a duplicate of bug 1472405 ***

Comment 13 Red Hat Bugzilla 2023-09-14 01:29:58 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.