Jump to content

The Unwanted Automatic "\*" Append HIPS Bug - EIS V15.2.11 (or even long before this version, back to 20220104 (?!?)


Recommended Posts

- please hand this over to your developers as fast as possible, but you can try it for yourself, everybody can do it in no time...

- this is a very easy to reproduce HIPS bug:

1. extend an existing HIPS rule with for example another ".exe" using the "ADD" button within EIS V15.2.11 and see what crazy thing happens: the selected EXE file gets an "\*" automatically appended!!! (See screenshots #1 - #3. #2 in german, a note by me, saying "extending existing HIPS rule 'xy.exe, write to file', DENY, appends unwanted "\*" to every new addition. Be it selecting within EIS or by copy-pasting!")

2. this doesn't happen when there is a new HIPS popup that you save.

3. now to the very bad consequences of this new and totally wrong automatic appending of "\*", see screnshot #1: here I extended an existing and working HIPS rule (20210720) at two different dates again (20220104, 20220707). Now, with EIS V15.2.11 'weekday.exe' is still working (all these EXE are shelled within different other programs), but not the other two EXE ('send-mail.exe', 'BarcodeGenerator.exe')!!! These two other EXE are completely hanging forever and eating one CPU core fully! It's impossible to KILL these, for sure not with the tools contained in Win7. (The 'cmd.exe' is eating one CPU core, the called EXE is doing nothing, if I remember it correctly. Both can't be killed.) The only remedy is a restart of Win7... (You can KILL them within Win7 task manager a thousand times, no error message, no KILL!) (Point #4 in screenshot #1 would mean "allow all files in directory '..\send-mail.exe\'", but 'send-mail.exe' is a file and not a directory!

4. I can hardly believe that I haven't used the 'BarcodeGenerator.exe' shelling since 20220104, but I will try to verify this (*). It could be that the HANG behaviour kicks in only since EIS V15.2.11?!? (*= checking the HIPS logs, checking previous settings export XML files.)

5. I will not check whether (see screenshot #2) a "write to file" with this automatic "\*" append will HANG the EXE in the HIPS rule too or not. It could very well be the case - again this "'xyz.ico' is a file and not a directory" "thingy"...

hopefully this will be fixed fast, #3 is a very nasty and annoying bug!

kind regards

#1-manually-extended-HIPS-rule-in-a-long-time-period---look-at-the-dates---20220104-is-suggesting-that-this-bug-exists-already-a-very-long-time!.png

#2-one-note-about-manually-extending-existing-HIPS-rule-file-ops-ie-WRITE-TO-FILE-20220705.png

#3-manually-extended-existing-HIPS-rule-with-the-ADD-button-ie-choosing-EXE-within-EIS-V15-2-11-itself!!!.png

Link to comment
Share on other sites

  • Administrators

It's a known issue which has been fixed recently. The fix will be included in the next HIPS module from the functional point of view and another fix in gui will be included in v16.

You can work around it by importing the path from file in the interim.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...