| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003063 | Kali Linux | General Bug | public | 2016-02-12 00:22 | 2018-01-29 12:32 |
| Reporter | William | Assigned To | g0tmi1k | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Product Version | 2016.1 | ||||
| Summary | 0003063: keepass2 crashes with several mono exceptions when deleting groups within a keepass2 database | ||||
| Description | While testing the migration to Kali Rolling, we observed and issue with Keepass2 that was not present with Kali Rolling where when an object is deleted from either an existing database, or a newly created database, with the latest package of Keepass2, after the application prompts for confirmation to delete the object, the left window produces a red 'x' and prompts if you want to save the database. When executed from the console, keepass2 appears to crash with the following message when we delete the object from a new or existing database, but keepass2 still remains up: (02/11/16 14:58:37)lorend@rad:~ Keepass2 then prompts if you want to save the database. If you save the database, it then crashes with the following output: Unhandled Exception: After deleting the object and saving the database, when we open the database back up, we get the following error messages: (02/11/16 14:51:02)lorend@rad:~ Unhandled Exception: If we choose to say 'Yes' when prompted to delete the the group, again we get the following output: (02/11/16 15:14:38)lorend@rad:~ What is different, however, is if we say 'No' to saving the database, it appears to also crash but with no other error messages. This environment consists of the following: (02/11/16 15:18:28)lorend@rad:~ In closing, we believe this to be a bug with with the 2.31 package of Keepass2, and while a tools upgrade request was opened to upgrade keepass2 in issue 0001945, we believe that package 2.28 is more stable than the present package 2.31, so we propose backing out of version 2.31, going back to version 2.28, or identifying the issue causing this behavior in package 2.31, which is currently marked as 'unstable'. | ||||
| Steps To Reproduce | This is reproducible in one of two ways, pending if you have an old Keepass2 database from another source. If you do not have an old keepass2 database from another source, do the following:
If you have an old keepass2 database from another source, execute steps 10 and on up above, specifying the old keepass2 database. | ||||
| Additional Information | Package 2.31+dfsg-1 is listed as unstable as per packages.qa.debian.org/keepass2.html. Package 2.28 is the latest stable package. When we download and install package 2.28 on a fresh install of Kali Rolling 2016.1 and fresh updates, we do not face these issues. We also notice that there is no 'Recycle Bin' object in the 2.31 version of Keepass2, which is odd. Regardless, even though the same behavior is observed with previous keepass2 databases, we attempted to recreate the 'Recycle Bin' group object as it is configred within the 2.28 package, but it still appears to crash when deleting objects. This testing was conducted on two HP ZBooks 17G2 laptops, one running Kali 2 and run running Kali 2016.1, both with with 32GB's of Ram and an i7-4810MQ Intel processor as well as a Lenovo W520 with 32GB's of RAM and an i7- intel 2860 QM processor. | ||||
 |
Hello, Sorry this is so long. Just trying to provide as much information as possible. So the testing we performed with keepass2 version 2.28 was performed on the Lenovo laptop, which allowed us to draw the potential conclusion that this was not an issue with the 2.28 version of the keepass2 package. However, after further testing, that conclusion might not be entirely accurate. When we perform this test using the 2.28 version of the keepass2 package on the HP laptop that we were originally performing the testing on, as demonstrated in 'Selection_001.png' the issue still persists. For what it's worth, this follow on testing was performed by initially, as the root user, purging the current keepass2 package from the system (apt-get remove --purge keepass2), validating that it was removed (some components were left behind such as icons), and installing the 2.28 version manually from 'https://packages.debian.org/source/stable/keepass2'. We then logged out of the profile and logged into a profile that had not logged into the system (e.g., fresh /etc/skel with fresh profile) and reproduced the issue with version 2.28. This leads us to believe that or original proposal was incorrect, leaving us to believe that something is messed up with this particular configuration or information system. Oddly enough, in both instances, we nuked and paved each information system with Kali 2016.1. We will work to conduct additional testing to troubleshoot this issue further, but this does not appear to be so cut and dry. To further assist with this issue, if so desired, I am willing to upload an impacted database created using version 2.28 of keepass2 after reproducing the issue, as well as an impacted database using version 2.31 of keepass2, naming them accordingly. To further troubleshoot this issue, on another Lenovo laptop with the same hardware profile, simply with a fresh Kali 2016.1 install, we only installed keepass2 using 'apt-get install keepass2' and attempted to reproduce this issue as the 'root' user, and we can reproduce this issue where the application appears to crash and present a red 'x' in the left window. We then purged the 2.31 version of keepass2 using 'apt-get remove --purge keepass2' from the system and, while the sha1sum of both repo packages are the same, manually installed the older version from the Kali pool (http://http.kali.org/kali/pool/main/k/keepass2/keepass2_2.28+dfsg-1_all.deb). This time we were able to reproduce the issue. One thing that we do know is that while exploring other options, we did install similar packages such as keepassx on the previous Lenovo laptop. Part of that effort involved installing 'mono-complete' so on the new Lenovo laptop we purged the keepass2 package, installed mono-complete on the same Lenovo laptop, reinstalled keepass2 from the kali repo, and attempted to reproduce the issue again, finding that it does crash as described. We then manually installed keepass2 version 2.28 from the Kali pool on the Lenovo laptop and attempted to reproduce the issue again, and it still crashes. From what we can tell, the one consistent piece of this involves the 'Recycle Bin', which does not appear to be present when we create a database. Given such facts, we went back to our old Kali 2 workstations and observed a few things:
Since this behavior is different, we saved a version of each database, one without a created 'Recycle Bin', created on the Kali 2 workstation using the keepass2 version 2.28 pulled from the Kali repo's. We then created another database, where we deleted a group object, which created a 'Recycle Bin' object, and saved the database. We then pulled both databases back to the second Lenovo laptop, purged and reinstalled the keepass2 package (version 2.21) from the Kali repo and attempted to open each database. When we opened up the database without the 'Recycle Bin' and it opened fine, but we were able to reproduce the issue as usual, however, when we attempted to open the keepass2 package with the 'Recycle Bin', it crashes, producing the following error: root@kali-testing:~# keepass2 Unhandled Exception: We then purged the keepass2 2.31 version from the laptop, installed the 2.28 version pulled from the Kali repo and attempted to open up each database generated from the Kali 2 workstation. The first database without the 'Recycle Bin' opens, but again crashes when we attempt to delete an object. When we attempt to open up the second database with the 'Recycle Bin' object, it again crashes, producing the following: root@kali-testing:~# keepass2 Oddly enough, additional testing with the database that does not contain a 'Recycle Bin' group object where we delete 'key' from the right window, it will not crash, but it will create an object like 'Recycle Bin', without a text label (icon only), with the deleted key found in the folder. Please see the 'new_database_delete_key.png' file for reference. We can then further open that database, but the icons on the left window are all screwed up, as described before. Please see reference figure 'william_new_database_reopen.png' demonstrating this. We then attempt to delete a group object on the left, and it crashes as before with the 'Cannot acces a disposed object' error referenced above. One last thing to point out is that on Kali 2016.1, we are able to open and modify the keepass2 generated databases, be they generated from a Kali 2 workstation, or a Kali 2016.1 workstation, using the kpcli utility. Outside of nuke and paving the HP laptop again, installing Kali 2016.1, and then only install Keepass2 and whatever dependencies it produces from the official Kali repo's using 'apt-get install keepass2' we do not know how to proceed. Any further assistance is appreciated. |
 |
Due to the age of the OS (Kali Moto [v1], Kali Safi [v2], Kali Rolling 2016.x), these legacy versions are no longer supported. Please could you see if you are able to replicate this issue with the latest version of Kali Linux - https://www.kali.org/downloads/)? If you are still facing the same problem, feel free to re-open the ticket. If you choose to do this, could you provide more information to the issue you are facing,and also give information about your setup? |
