dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
3309
share rss forum feed


gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1

Kerio potential vulnerability ... app masquerade

Due to an ongoing issue regarding "app spoofing" in Kerio PFW, it's been discovered that the issue, discussed there regarding Beta 5, is still present in the 2.1 release. Briefly stated,

1. the original vulnerability involved the renaming of any HTTP aware application to PERSFW.exe and placing it anywhere on the local filesystem would grant the program access through the firewall to any remote host on remote port 80 (Kerio, all beta versions, and Tiny, all 2.0.15 level releases).

2. the present release version of Kerio, v. 2.1.0, attempts to fix the vulnerability, however, if the masquerading file is placed in the binary directory of the firewall (by renaming or deleting the legitimate binary) the vulnerability is still present. The overwritability is a natural vunerability of windows, filesystems; anything accessible by the logged in user can be changed by a script, etc. ...

3. the vulnerability arises because the binary is either exempt from or subject to certain implicit rules in the firewall that allow it to obtain access without checking for a valid MD5 or logging any information about the access(it is the service component of the firewall on an NT system, that is, it loads and releases the lock on the file after services controller takes control of it, leaving the file unlocked and vulnerable to replacent. It's function seems to be parsing the configuration and providing the user an interface with the firewall core engine, a kernel mode driver).

I think that about sums it up. In a brief run through, if a file named PERSFW.exe is placed in the firewall binary directory of Kerio PFW v.2.1.0, it can gain access to the internet and connect to remote port 80 on any remote host. This has been confirmed by several users, and is discussed in a little detail in the Kerio-Tiny group at »What do you make of this?

The potential risks are (1) that an unauthorized application could be trojaned to the firewall directory, and, without giving any notice that the file has been replaced, it could ask for and obtain from the firewall free access to any remote host port 80; (2) as suggested by the foregoing, it would gain access without regard to the validity of its MD5 "fingerprint". (3) the file could be replaced with a nonsense file, or just removed, causing the interface component and service component of the firewall to fail to load on the next boot, which may rise to the level of a sort of denial of service.

There are no known exploits of this vulnerability in the wild, as of this time. Stanislav Kolar, the lead developer at Kerio, has been responsive, and has assured at least one correspondent that he's aware of the discussion, and will be releasing a 2.1.1 version very shortly.

In the interim, I just feel that it's important for users to be aware that we still have an ongoing issue, here, and consider coming releases potential "mandatory upgrades". It's probably best for anyone using the beta versions of Kerio to upgrade to the release version, since the issue is significantly narrower (the malware would have to be placed in a specific directory) and more specific in this release. All users are well advised to be aware and alert, and watch for, and install, any patched versions which may be released.

Tiny Software has not yet addressed the issue, but indications are there that they may be in covert development of a version 3.0 as they had once indicated. Meanwhile, ongoing development at Kerio is pretty steady, right now. I have no reason to believe that Mr. Kolar is not working on this as we speak, so there's no "call for panic," at this time, just a prudent warning to protect your firewall directories. In fact, I think that's prudent advice with any PC firewall. Just be a little more alert, with the latest release version of Kerio, and upgrade or patch as soon as something is available.

Tiny 2.0.15 is still vulnerable to this app spoof filesystem-wide. Kerio, current level, is vulnerable only from the Kerio binary directory.

Meanwhile, (and my initial experiments indicate that this may work) it may be a fair idea to place a "deny" rule at the very TOP of the rulesets, temporarily and until we confirm a better solution, in the form set forth above...

While the firewall won't log the accesses, at least in my own experiments, the alert DOES show the access, and I was unable to sniff any traffic making it through the firewall, with this rule in place.

This is natually a quick and dirty fix, not a solution. We still have the issue with the potential for a simple, script-kiddie attack to create an inconvenience by just erasing the file. But a LOT of PC firewalls are subject to variations on that sort of nonsense. Good computer hygene (limit scripts and activeX, careful what you run, scan for virii and trojans regularly, etc.) is never a bad idea, overall, regardless of the firewall.

Just to anticipate the questions, my initial research indicates that this may (and I stress, may, they're pretty mum on the details) be related to integration of the firewall into CMDS centrally managed enterprise environments, where the firewalls originally evolved. Whatever the reason, it needs a more "elegant" implementation. This may have some serious longer term implications, if it isn't patched up. These are just too good, as firewalls go, to have this trivial a vulnerability. Needless to say, if my guess about this is right, this isn't good for a CMDS machine, either, as the employee at the workstation might be able to evade remote monitoring or configuration changes, somehow, using this (catch22, since I suspect that's precisely what it's supposed to be used to prevent). So I really hope they move quickly on it.

Well, that's the short and sweet. More details will be posted, as will any patches, as soon as available. For now, be aware, don't panic, and stay alert.

I make no guarantees that the rule above will fully address this, but I think it's a prudent stop-gap, and I think they do intend to address our concerns soon.

We'll continue following it, as much as possible, and we'll keep everyone posted if any exploits or fixes are encounterd, in the meantime.

The "uber-users" may wish to put a "read only" flag on the persfw.exe file, just remember, this may screw up an install later on, if you forget to REMOVE your read only flag before an upgrade.

The super-uber-power-users may want to tinker with file access permissions. I don't particularly endorse that, unless you know what you're doing. Even I've locked myself out of NTFS files, that way, once or twice. Be warned. Also, a Win9x/Me file is always vulnerable to any masquerade or file replacement exploit, and there are no permissions on FAT; it's pretty much the nature of the beast, and that isn't a Kerio/Tiny problem, it's just part of the windows architecture.

The big issue, here, really, isn't that part. We face that challenge all the time, with all sorts of PC firewalls. But what disturbs me is the potential for abusing this as a "backdoor" out of a system, and the fact that the firewall doesn't cover it's OWN back with an MD5 check on that file.

Just a suggestion, but, if it is, in fact, required for a CMDS implementation, the difference could be split by incorporating a switch, password protected, to disable the functionality for home and personal stand alone installs...

Tiny is still vulnerable to the original issue.

PS- the second visual aid shows the methodology of the test, and the placement of the rule that "I" thought seemed to kill it. (again, this is confirmed only by my so-far very un-empirical testing)... I make no guarantees it will do the trick, but I did think it deserved to be mentioned. The "test" rule was created simply to try to create logs for the testing. It's dangerous as a standing rule, and doesn't belong enabled in ANY ruleset, unless testing is actually in progress!!!

We now return you to your regularly scheduled program, already in progress... good sailing, and safe surfing...
--
Und lümmelt sich in Bars...?


[text was edited by author 2002-03-11 15:39:30]
Note: others have reported that the rule doesn't work, for them, so I don't want to appear to be suggesting it as a fix, so I removed the screens... now I just have to replicate what I did, see where I screwed up, and see if it can be done by anyone else, I guess...
[text was edited by author 2002-03-11 20:13:10]

[text was edited by author 2002-03-11 20:15:00]


Sentinel
Premium
join:2001-02-07
Florida
kudos:1

said by gwion:
Well, that's the short and sweet.
You may be accused of being many things gwion, but short and sweet will never be one of them. LOL

Thanks for the heads up.
--
AL

[text was edited by author 2002-03-11 15:42:50]

New Years$

join:2001-12-20
reply to gwion

How does Kerio handle this and some of the other virus out there that has the ability to tunnel.

TROJ_OPTIXKILL.A

Size of virus: UPX Compressed=17,410 Bytes

Details:
Upon execution, this Trojan terminates running antivirus programs. After 30 seconds, it also terminates monitoring applications. It can also terminate services.

The following is a list of Executable files and services that it terminates:

http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_OPTIXKILL.A&VSect=T

This non-destructive Trojan terminates antivirus programs and kills services. It also adds garbage entries to the registry.

Solution:

TROJ_OPTIXKILL.A.
Restart your computer.
Click Start>Run, type Regedit then hit the Enter key.
Double click the following:
HKEY_LOCAL_MACHINE>Enum>PCI
Look for this registry entry and delete it:
RZNSSS.

It is my understanding that some oversea have seen other programs on blackhat chat rooms that are targeting AV, AT, and firewall.

I did not post this to single out Kerio..but since you guys seem to have really done an excellent job with it to date.. I wondered if you could tell us just how prevelent these attack are on the Security products.


gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1

reply to gwion

Well, it's not in the wild (that we know) yet. That's a relief, if a minor one. NT 2K XP users, services CAN be protected more significantly than regular apps (the simplest way is not "surfing root", but I don't want to go there, that may be pretty OT; 9x/Me users are at the mercy of their OS architecture, alas. "Service" is pretty meaningless, security wise, on a 9x machine. "Security" can be called meaningless, on them, in the "native" sense, too, in fact, but, again, I digress (-- as usual, Al ) ... worth mentioning, though, thanks... I do apologize for my wind, [again;)] but I wanted to try to cover the bases in one post, just so everyone is aware of the background...

anyway, good point, New Years. Any "firewall" you run locally is subject to certain exploits that a remote, dedicated firewall machine isn't, or at least isn't AS vulnerable to, if it's well designed. Problem here has to do with the fact you're sitting at the same machine running content... so the firewall's being controlled by the same OS that the malware is running on. Which simply underscores my own personal first axiom of computer security. "Perfection" is a fireaxe. "Protection" is a firewall. No PC firewall ever made can anticipate everything, and they have architectural limitations just because of their interaction with the OS and the user. That just means that having a firewall isn't invulnerability, far from it. You still have to be aware of and get in a habit of general computing hygene.

PS- also, I'm still watching progress on Tiny Trojan Trap, which seems to address just these sorts of problems... including even an issue, as described in the first post. I still consider it a little buggy, myself (my own principal machine is an SMP, for example, and there were some identified issues on such systems in the last release looked at...) but it's a VERY promising app layer sandbox, and i think it's well worth watching...

--
Und lümmelt sich in Bars...?

[text was edited by author 2002-03-11 17:33:51]



Murray3

join:2001-03-06
Texas
reply to gwion

Thanks a lot for taking the time to post that very comprehensive warning gwion.

Very much appreciated.


New Years$

join:2001-12-20
reply to gwion

Thanks...and keep up that wind please that is how we have all be able to learn not only what is happening but also why as you share your thought in that manner.



OzarkMan$

join:2000-12-22
Ozark Mtns.
reply to gwion

Appreciate the info gwion give him his own Kerio Forum and that STILL isn't big enough


Traduk

join:2000-10-25
England
reply to gwion

Gwion,

If it needs to rename or replace the existing persfw.exe. Wouldn't a temporary fix for the hypothetical problem be to just make it "read only" until a permanent solution is found?.

Traduk


BlitzenZeus
Burnt Out Cynic
Premium
join:2000-01-13
kudos:3

Its so easy to un-attribute files its amazing so just making it read-only is pointless....

I can write a simple batch file to remove the attributes right now, and it won't even take me a minute. The script could also rename, and run the program of my choice too!
--
"Yesterday we obeyed kings, and bent our necks before emperors. But today we kneel only to the truth." -Kahlil Gibran



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1

reply to gwion

Good to highlight that. I think that sounds like the (easiest) single thing a user can do, for now, as a real loose, fast bandaid fix. Just REMEMBER you did it when the new version comes out!!! Otherwise, I don't think you'll have a smooth upgrade install experience...

PS... right, BlitzenZeus. But I still think that it's a good idea to intyroduce as many variables as possible into the discussion. The harder you make the file to replace, the better, I figure, even if the file can be reached trivially...

the BEST advice, I guess, is always, technically, "don't surf root, and use very restrictive permissions" ... but I break those rules, myself, and we don't like to hear that, really... plus, I've managed to render a few files undeletable by myself, playing with permissions too flippantly. [ed.: and not everyone has NTFS, anyway] So, yes, that could be handled by a simple script or batch, and security by obscurity stinks, but sometimes anything's better than nothing... it's a personal comfort decision. Me, I'm going to read only protect mine, even though that's trivial, and I run the rule, even though I haven't proved it works beyond any doubt... I have difficulty, myself, telling people "do this." I prefer to say, let's try this, and see how it works... remember, there is no known exploit wild to use as a benchmark... and no, I don't "hope one comes out." This is pretty trivial to prove and experiment with on our own, and if we don't know how, it's best we don't try... for the sake of our own systems... we don't need a grey hat proof of concept ...

I just submit that all workable suggestions, that set up a workable barrier to the most egregious exploits, are good ones. In an imperfect world, sometimes introducing enough randomness into exploitability at very least reduces the percentage of systems on which a scripted or amateurish exploit will work... which is a step in the right direction, for starters...

--
Und lümmelt sich in Bars...?

[text was edited by author 2002-03-11 19:44:03]

[text was edited by author 2002-03-11 19:45:34]

[text was edited by author 2002-03-11 22:44:41]


Traduk

join:2000-10-25
England
reply to BlitzenZeus

BlitzenZeus,

It was just a thought. Obviously far too simplistic on my part. It would be just one more, possibly unexpected hoop for a potentially malicious hacker to have to jump through.

It looks as though Stanislav will have to nail this particular problem down once and for all, as spoofing and getting through firewalls from the inside /out appears to have grabbed more attention than the original functional requirement of keeping the bad guys out.

I have seen the scripts you possibly mean which have been attribute changes for backing up registry files and they are simple Dos strings?.

Traduk



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

Right. There are admin scripts posted on the internet that do that 5 for a dollar. Simple cut and paste. But, like I said. It's a step in the right direction in an imperfect situation in an imperfect world. Now, another dimension is NTFS permissions. I was thinking about that. One big problem is that the cfg and logs and all are in that directory, so you can't just deny write access on the whole directory, I've tried with Tiny, and it screwed the firewall up (a technical term for it didn't work right ).

That's the most promising direction I see... uh, but a script, if the logged in user is admin, can change file permissions, pretty trivially, too, eh? /scratches head/
--
Und lümmelt sich in Bars...?


BlitzenZeus
Burnt Out Cynic
Premium
join:2000-01-13
kudos:3
reply to Traduk

My point is, simple things like marking files read-only will not stop someone from doing actions like this unless your using NTFS with strict permissions on a restricted account.

One point needs to be made though.... Most people have found that Tiny/Kerio will not run correctly unless the account has admin access to your system. That would allow any program running full access to your system anyway.

The thing is I can write these script, and don't have to find them on the web. Most of my scripts are dos based, but i'm not limited to using dos batch files either....
--
"Yesterday we obeyed kings, and bent our necks before emperors. But today we kneel only to the truth." -Kahlil Gibran



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

... look around. I found a collection of vb scripts a while back, somewhere, can't remember, now. Of course, I think they required reskit. The risk is there... only real thing I think can be said, really, is "fix the software!" It would be nice to have a universal stop gap, but, short of a Tiny Trojan Trap type app, I don't thank there are any "quick fixes" for this kind of thing. App masquerade is one of the oldest tricks in the book. Best advice is just be aware and be alert for fixed software and further details.
--
Und lümmelt sich in Bars...?



Wildcatboy
Invisible
Premium,Mod
join:2000-10-30
Toronto, ON
kudos:3
reply to gwion


Masquerade vulnerability is a serious issue in personal firewalls whether it's in the same directory or in any directory. The only way to assure the problem is fixed is to have the firewall check for the MD5, etc... file signatures. Now basically all personal firewalls that are currently invulnerable, do that and this included Tiny and Kerio. This begs the question as why kerio makes an exception when it comes to persfw.exe. Even after they fixed the masquerade vulnerability in all directories, they still refused to check the file signature or log its activities and that's something I really would like to know the reason for.

Why would a firewall refuse to check or log where a single file is going? Not all files but a single file. A file by the way which is supposed to go out somewhere and download something to your hard drive for the upgrade purposes. That keeps nagging at me ever since I found out about this problem. A workaround would be to go back to the last version of Tiny before the auto update capability as this whole problem started with the auto update feature, however I'm afraid the last version of Tiny had its own vulnerability which should be considered just as bad if not worse.
--
You can catch the Devil, but you can't hold him long.



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

... in a proverbial nutshell. nd this begs another qustion, really, which is that even if this does have anything to do with the integration of the firewall and CMDS system, or the autoupdate, why would you introduce an insecurity in order to implement a convenience? I can't see how either explanation justifies creating a problem like this in a firewall that's otherwise so good. Has the Microsoft menatlity, of transparancy and ease of use become so pervasive that we even sacrifice rudimentary things like signature verification in an app designed to provide security as its mission, and pne of the best products in ts class, to boot? If so, what can we trust? Now, I'm not addressing anyone in particular, here, just taking a second for a philosophical rant... I've always said, convenience and security are a trade off, you can't have all of both, you have to find a spot in the middle to be comfortable with. But this isn't it! The decision to forego this kind of security for convenience in a product like this should always be made by the end user, not by the developer or a third party. If it's autoupdate, and if it can't be done some other way, lose autoupdate. It would encourage people to visit the website and stay up to date, maybe buy some other products, anyway... or am I missing something, here? That's just my two cents. These are both companies that I think have earned a reputation for integrity and proactive development with a lot of people. I want to see them keep that trust.
--
Und lümmelt sich in Bars...?



Wildcatboy
Invisible
Premium,Mod
join:2000-10-30
Toronto, ON
kudos:3


What bothers me is that logging the activity or checking for the signature does not reduce the convenience of having an auto upgrade. They really have nothing to do with each other. What's wrong with logging the auto upgrade and doing it at the same time? Why shouldn't a firewall ask me if I want to upgrade before going and doing it? It's just an extra click, isn't it? And why shouldn't it log the activity? That's why I'm hoping for a direct answer.
--
You can catch the Devil, but you can't hold him long.



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

In fact, isn't that preferable? Just sound computing hygene and sense to keep a good audit trail on every little minute detail with this kind of software
--
Und lümmelt sich in Bars...?



Sentinel
Premium
join:2001-02-07
Florida
kudos:1
reply to gwion

Perhaps I missed something here, or this is too simple but why doesn't Kerio check its own MD5 signature? Wouldn't that stop another app from masquerading as Kerio's exe?
--
AL



Murray3

join:2001-03-06
Texas

said by Al Otero:
Perhaps I missed something here, or this is too simple but why doesn't Kerio check its own MD5 signature? Wouldn't that stop another app from masquerading as Kerio's exe?

That's the whole issue. It doesn't. I mean, I think it doesn't even create an MD5 for persfw.exe. (It doesn't on mine that I can see). Seems like a pretty fundamental thing, I agree.

I'm sure the next release will address this whole issue.



Wildcatboy
Invisible
Premium,Mod
join:2000-10-30
Toronto, ON
kudos:3
reply to Sentinel

You didn't miss anything Al Otero. That's my point. They don't check the MD5 signature for that file and they don't even ask you permission for the real file when it wants to go out much less a malicious file. And of course they don't log any activities by the main file which means a Trojan can go out without asking permission and it won't even be logged.

The problem is that even after they fixed the original problem which was masquerade vulnerability in all directories, they still refused to check the MD5 or log the activities which bought us to the existing problem. It remains to be seen how they are going to fix this but if they still refuse to log the activity or ask permission for the file, I'd be quite hesitant to use it.
--
You can catch the Devil, but you can't hold him long.



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

As I see it, that would be the number one concern, yes. But it DOES create one. That's what really surprised me. Creates it, but doesn't USE it all the time, evidently. When I finished these trials, I pressed my "clean out obsolete MD5's, and, sure enough, it flagged "persfw.exe" as being changed or missing. So it does ... wait ... yep, it's there... checks out OK, now (as it should). So... why isn't it being used? That's what mystifies me.
--
Und lümmelt sich in Bars...?



Sentinel
Premium
join:2001-02-07
Florida
kudos:1

reply to Wildcatboy

Well I guess I phrased that wrong. I guess I meant to say why doesn't it check its own MD5? What is different about it than any other application? It checks the MD5 of all applications that send traffic out through it, so why does it not check that particular app? Almost seems as though they wrote it so that it excludes itself from MD5 checking doesn't it?
--
AL

[text was edited by author 2002-03-11 22:45:24]



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

Yeah, that's what bothered me. Even if there's a perfectly logical explanation, it still doesn't make sense that an app would be allowed to SPOOF the legitimate binary. And let's not lose sight of one other detail. The remote access defaults to "any" remote address... that isn't good, either. If something's an upgrade or a management feature, it never has to map to "any" remote address! Now, this makes me wonder about a few things, myself. I have a feeling I'll be doing a few tests when I get hold of a new copy, myself... not just academic interest, either. This isn't good behavior; we shouldn't need a firewall for the firewall...
--
Und lümmelt sich in Bars...?



davidovv

join:2001-06-19
Netherlands
reply to gwion

gwion,

Hate to interfere, but Optix Killer v2.0 is ITW:

quote:
Well, it's not in the wild (that we know) yet.
Keep up your outstanding work!

regards.

paul

»www.wilders.org security

New Years$

join:2001-12-20

I knew that..just did not want to rush the gurus. Keep it over there will ya!



davidovv

join:2001-06-19
Netherlands

. Sure New Years; It's locked up safe and sound!

regards.

paul

»www.wilders.org security



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

Thanks, and I always appreciate your remarks... looks like we're going to be talking integrated system security, from here on out. Sandboxing and multilayered solutions. The development trend with the whole WinRoute-Tiny-Kerio-CMDS line of security solutions has been fascinating, and, I think, illuminating. They stunble on their shoelaces, now and then, as all developers do in trying to improve their products, but they seem to be slowly diverging from the simple port blocker model of firewall design and towards the integrated approach. Tiny Trojan Trap is an exciting product, to me. It's much more than just a trojan app. It's a full blown system wide sandbox environment. Granularly controllable. Amazing. On NT, the software created the most restrictive, granular application layer control of anything I've ever seen. Unfortunately, it doesn't yet run on SMP machines. I can't test it, anymore, for now. But the beta was fantastic, if a little awkward.

Kerio now has a few limited app layer enhancements; for example, it detects and blocks kernel mode drivers from loading without authorization, and detects blocks raw socket connections. This is where we have to go. Screen doors aren't working. They never worked. That's why I'm so concerned with an issue like this. It seems to me that any value that serves for any feature is negated by the insecurity and vulnerability... the trivial vulnerability... it creates, to just the sort of tampering -- scrpted and physical tampering -- it's supposed to be preventing! They're screen doors. No chain is stronger than the weakest link. There are enough "screen door firewalls" and glorified proxy servers on the market.

By the way, we're advised that a release note is now posted at the Kerio website for a 2.1.1 release... Hopefully, this will fix this issue. We can get back to helping users again. However, the binary isn't uploaded, yet. No, coordination between the dev team and the webmaster has never been a strong point at Tiny or at Kerio, it seems... sooo... let the vigil begin.
--
No, I cleaned up the root partition and now there's lots of free space...



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

Status update...

As of this morning, the release notes have been expanded to indicate that the 2.1.1 release, when available, will prevent renaming of PERSFW.exe while the firewall is running. Just a heads up, and a reminder for users, we'll post a link to the new release, when it becomes available, in the Kerio-Tiny forum, and I'll try to link it here, too, as soon as I can.
--
Well, if I knew it wasn't going to work, I would have tested it sooner.



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to gwion

2.1.1 is released...

... release notes indicate that the new release addresses "renaming of PERSFW.exe while the firewall is running." Until I have time to get a copy installed, myself, I can't verify, but I believe, in light of this discussion, it's an important update. The link on the Kerio site is still pointed at 2.1.0, but this link »download2.kerio.com/dwn/kpf/keri···1-en.exe should be good. More info will be posted, as available, in the Kerio-Tiny support forum...
--
Well, if I knew it wasn't going to work, I would have tested it sooner.