Discussion in 'other anti-malware software' started by ZeroVulnLabs, Oct 15, 2013.
we're about to release the auto-upgrade to 1.07 build 1015 on Monday.
Few pages back, since version .1010 (page 91) I complained that on XP my Seamonkey, Outlook and few office applications weren't logging much of the time (even though mbae.dll was injected), MBAE didn't issue a popup and the shield count seemed incorrect, usually leaving a value of 1 bound to a specific application.
New version .1015, with shield count removed, works great. Everything that should gets a popup and is logged.
Thank you, ZeroVulnLabs, great work
Ah. The text formatting really did it. On Monday build 1015 will auto-upgrade build 1015. So I'll start out with the not-auto-upgrade build 1015 that I'm running now and later with auto-upgrade build 1015. If that needs correction, don't forget the bold and italic text.
I've always upgraded overtop of existing version, don't ever remember having to reboot. 1015 running good here.
I still wonder why MBAE not cover Thunderbird, Skype, STEAM client, Raptr by default
IMHO too common software with too many attack vectors to be ignored ...
Go and buy it dev has decided this way, maybe they change it a bit in future.
ye well the exclusion of PDF readers considering theirs holes is strange too
and definitely indicated the push-point for sales
but what I mean there is no preset on the paid version for Thunderbird, Skype, STEAM, RAPTR either ...
IMO those are collected as "others"
Not sure what you mean by collect, but in the strict definition of the word, MBAE doesn't collect anything. Shields need to exist or be added for mbae or mbae64 dll injection when the processes are executed.
I wondered about the exclusion of Thunderbird. I think it's more that everyone these days is doing email on the Web in a browser and not the "dev has decided this way" so you need to "go and buy it."
I added a browser shield for Thunderbird.
As for the defaults for "too common software" not covered: Yes, for all the ignored too common software, one needs to go and buy MBAE. Which is what I did for my too common software, eighteen shields so far. I think I got 'em all.
The decision for inclusion of a new default shield typically follows these guidelines:
* Is the application popular and Internet-facing?
* Are vulnerabilities and exploits published regularly & publicly targeting the application?
* Is the application targeted by cybercriminals in the wild with weaponized exploits?
If the answer to these three questions is YES then it would be considered for inclusion as a default shield.
I agree, I miss this simple little feature.
Maybe Malwarebytes can make it an optional setting, rather than having it off by default?
You can backup/restore your custom shields by making a backup of the applications.dat file from the MBAE user data directory.
at minimum STEAM (50-100 million users), Skype (250-500 million users) and more likely Thunderbird (5-20 million users) fits those 3 questions with yes
Please share some research claiming that steam, skype or thunderbird are being exploited in the wild using exploits. Sending executables in a zip file is not an exploit and the fact that vulnerabilities in these pieces of software are being patched is also not a valid argument. (vuln != exploit)
In that same thread seven month old thread you failed to notice Pedro's, um, disclaimer, "Only in the case where we implement new custom shield functionality is when they have to be re-created." That is, the previous data file... worth nada.
Even without considering I already knew that, your reply has absolutely no relevance to my request for a far more elegant export/import feature, including settings. The exported data would be in a format (i.e. XML) for migration into the new custom shield functionality via import. There's nothing new about this.
5000 million... WOW.
No. Only the one. And with over 3 billion Intuhwebberz out there, the numbers you cite as popular is a bit of a stretch.
one zero wild, damn typo
there were some, some are fixed and you too naïve if you think there are no yet to be revealed
ye list of actively protected apps 'right now' would be helpful to be sure all works like it should
Okay, in that case provide some evidence that these vulns have been exploited in the wild to gain remote code execution.
Nope, I am not naive. If you can provide concrete recent (so not exploits that date back to 2010) reports of exploitation attempts then I am happy to change my opinion, I am also not aware of all exploits that have been used in the wild.
But saying that certain exploits might exist in the wild without providing any evidence is a bit too easy.
I would never want a shield for Steam, considering that the client uses VAC (Valve Anti-Cheat).
Any program such as MBAE, EMET, HMPA that have Steam shields/protections in place (Custom or Default) will get a Steam user perma banned.
Basically, anything that modifies or injects into the Steam client is a big no, no.
You know what, that had never occurred to me - so I'm glad you pointed it out. At one point I had considered using EMET on Steam, but decided it wasn't worth the effort compared to my perception of the risk of encountering an exploit.
Now having had a look after being prompted by your post, I found this old thread on Steam, where a user (A20) made a dummy account which was promptly perma-banned for manually using EMET on HL2/CSS:
As a side-note, that thread is a good example of where people refuse to address what is apparently a very simple question by an OP. Some gave good context why he might not get an answer from Valve, but others kept arguing with him that he didn't need EMET. It reminded me a bit of this exchange:
Neo: What are you trying to tell me? That I can dodge bullets?
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't have to.
Neo: Yes, but will I be able to though?
Morpheus: You won't have to.
Neo: But... if I wanted to-
Morpheus: You won't have to.
It only first the first question. It does not fit questions #2 and #3 as there are no public exploits being used in the wild to target these applications.
Not an RCE vulnerability, or something that MBAE (or EMET/HMPA) can cover.
Separate names with a comma.