zhladik
-
Posts
20 -
Joined
-
Last visited
Posts posted by zhladik
-
-
At end of last week ESET released Internet Protect module V1475 (also may be 1475.1 have same problem ?) which caused big mass problems to NodeJS based applications including Github Testing tools etc. Topic is discused In this forum thread https://forum.eset.com/topic/40702-eset-ssl-protection-produces-an-invalid-certificate-chain-for-nodejs-apps which is accessible without registration but with broken Captcha so it is almost impossible to write to the thread. Reason of breaking of NODEJS is moving Node.exe based application to area of implicit TLS inspection. To be able to do it Eset must inject local special certificate CA to list of trusted CA certificates. Usually it is handled by Windows Certificate storage or by explicit handle of well known browsers or other handled apps. But NodeJS uses hard-coded CA list (?) and ESET overlooked this problem. Fix in V1476 of module probably simply removes nodejs from filtered TLS. But it is NOT SECURE SOLUTION. I suppose ESET tried to add filtering because malware uses javascript very often. So there is very usable to inspect TLS communication from secured computer. So as there is cookbook about manual adding of "ESET Filter CA" to list of trusted CA's let's switch TLS checking on even after fixed version revert implicit exclusion of nodejs TLS check. There is possible to use automatic script for export and add CA, I will send script to github repo https://github.com/the-last-byte/ESET-NPM-Breakage-Fix . So use it is good step to improve nodejs security. After this you can switch ESET Explicitly on check of node.exe.
-
Thanks for info.
I looked for proper ulr's for on filed download and BTW I discovered the existence of a Full Package (4x bigger than normal one - nt64_full.msi vs nt64.msi).
This can be usable on an infected PC disconnected from the Internet (?)
Script for download on field on customer site with wget:
Quote:: download actual EES from reposet Act_EES10_Version=10.0.2034.0set Act_EES10_FName_32=ees_nt32_%Act_EES10_Version%.msiset Act_EES10_FName_64=ees_nt64_%Act_EES10_Version%.msiwget -Sc -O %Act_EES10_FName_32% https://repository.eset.com/v1/com/eset/apps/business/ees/windows/v10/%Act_EES10_Version%/ees_nt32.msiwget -Sc -O %Act_EES10_FName_64% https://repository.eset.com/v1/com/eset/apps/business/ees/windows/v10/%Act_EES10_Version%/ees_nt64.msi:: full version with all modules from date of release - for offline emergency usage (200MB vs 50MB - no modules)set Act_EES10_FName_32=%Act_EES10_FName_32:.msi=_full.msi%set Act_EES10_FName_64=%Act_EES10_FName_64:.msi=_full.msi%wget -Sc -O %Act_EES10_FName_32% https://repository.eset.com/v1/com/eset/apps/business/ees/windows/v10/%Act_EES10_Version%/ees_nt32_full.msiwget -Sc -O %Act_EES10_FName_64% https://repository.eset.com/v1/com/eset/apps/business/ees/windows/v10/%Act_EES10_Version%/ees_nt64_full.msi:: extracted from
-
Thank you for quick answer. Yet one question: Can you please publish URL for downloading of this version installation package? May be also other older version download possibilities will be usable.
-
I got an automatic program update from 10.0.2034.0 to 10.0.2045.0 (I found that I configured the prerelease version update channel). But - after installation, it shows the link to the info page with old release notes of 10.0.2034.0. And nowhere on the web and this forum is info about this release. I think pushing any version without info is very bad idea, even for prerelease channel versions. Please push developers to publish pre-release info BEFORE enabling installation next time and post actual version info here...
Even on testing PC is nice to know what changed and what to check for .
Bad feelings is magnified by the publish date collision with MS patch Tuesday.., I was afraid of the quick hotfix of MS compatibility problems.
-
On several customers Win 10 installations I found some FW rules after upgrade 9.1.20560.0 to 10.0.2034.0 replaced by Strict Disable Rules without label (on cfg XML export labeled as IDS_CONFENG_GENERAL_UNTITLED_LABEL) Those rules disables all incoming TCP/UDP.
It seems that upgrade replaced some rules not labeled as learned. New rules by wide disable settings also shields all rules in lower order in rules table. I was not yet verified this by reproducing on clean Windows
I believe that reproducinf scenario is:
- W10 with 9.x (in PCs it was probably from V8.x upgraded also).
- Switch Fw to Interactive mode
- Start some app which forces ESET Dialog for rule creation
- upgrade to V10.x
- check if rule was changed to Disable all incoming TCP/UDP
May be it destroys only rules for exe binaries which are uninstalled, or served by other rules?. Lot of similar rules untouched, some replaced.But main disaster is made by shielding subsequent rules. May be there is some inconsistency inherited from older EES versions (Generally errors alerts about rules table problems is very long time persisitng BUG 😕 ).
I will fill tickets ASAP, but before I will try to reproduce it on clean system.
So for other users hit by this BUG - remove unlabeled FW rules, or if it is possible - better solution: clean Rules table and switch to learning mode. (cleaning of rules table is little (almost hidden) grey 180deg turn arrow icon (in V10 I see it is more contrast one used - great!)
-
Maybe I am wrong, But it seems that each several years someone of update files mirrors goes to inconsistent state with missing files.
Now We got every several hours from some of about 150 EES clients (latest 9.1.2057.0 version) Error message about this. All update related settings in default state...
So it seems that ESET does not use any consistency check script for update servers network? Or Update distribution scripts leaves incomplete copies accessible on some server?
I tried to solve it on phone support, but they want to catch Log dumps. But error repeats rarely, so I can not catch it.
I see that exactly same problem appeared several years ago:
Probably somebody in Eset fixed by hand after few weeks mirrors inconsistency? But it is not solution. Solution is consistency check script of mirrors to avoid even rare occurrence...
-
But Firewall is simple rules table, If I tried to add rule for Application (Yes I know to move it to start of table), it did not unblock. Historicaly Eset FW is not nice piece of code. And it seems new developers are not able handle old code very well 😞
It is probably hooked some weird way to HIPS. And BTW - there must be somewhere table of blocked Apps - but nobody knows how to access it. And probably in several latest updates some developers tries to clean relations and screwed things totaly....
-
This is very old problem - It appears on different apps changes randomly but not very often. Result is always same. App is silently blocked, no rule in FW helps. Only fix is exception rule for app change detection . Eset module (HIPS - no Firewall - i just got confirmation from support person) detects app change (and valid singing of app does not help). A writes somewhere deep in eset on some inaccesible table that app must be blocked. last week i met it on 4 machines blocking Chrome, Today it appeared on Firefox...
BTW I asked several times in different forums about ESET buglist or fixlist, Anybody here knows url of FIes/Bugs descrion on Eset produkts?
-
On 6/25/2021 at 5:08 PM, Marcos said:
I for one don't know any other source of information about the latest version except the download page. You can contact your local ESET support but I assume these are the only ones.
But just again - there are new files few minutes now - 8.1.2031.0. No announcement - binary name without version from fixed url and of course sha checksums changes without warning. Only check of install binary signing helps to trust. I thing faster (automated?) sync version number with kb3040 page will be nice. Thanks....
-
Sorry for bad subforum - right one is "ESET Endpoint Products". But question is quite general... Remote managements handles repository versions Info, but parsing metadata is not easy....
-
Hi all,
As Marcos mentioned in this forum - new version of EES just released. Because I wrote scripts for automated checking of new version I got alert about it but not via version page - https://support.eset.com/en/kb3040-check-for-the-latest-version-of-your-eset-business-products, but via hash checking alerts. There is till now still old version info. Binary URL is constant link to the latest binary https://download.eset.com/com/eset/apps/business/ees/windows/latest/ees_nt64.msi. I know about metadata file on https://repository.eset.com/ but it is complex binary/json mix with all ESET products including localized versions.
Is there any simpler way to get the latest version number from ESET repos/sites?
Thanks Zdenek Hladik
-
Hello,
We got to troubles with very slow Internet banking pages of "Komercni Banka". So I found option for adding web site to list of controlled pages with option where to show page - In common or in secured browser.
But this does not work! Probably of precedence of hardcoded banks list?
I don't understand why this function (several years implemented on home grade variants of ESET AV) is crippled this way in business variants. On home product there are three option use/ask/don't use. Here is "ask" option omitted and custom list is overloaded by hardcoded list of banks...
So there is only option to switch off secure browsing at all until EST/KB solves problems...
-
Update: it seems now problem is fixed and last files have right date and will refresh all caches...
But it is good to know - dont trust ESET update mechanism (complicated, unefective and fragile)
- if long time from last update passed - try to clean caches and check updates
version on ESET pages:
-
Hello,
Today evening (about 18:20 GMT) there something wrong happened to date setting on servers for generation of control files for virus database updates.
From this time RAR files have datestamp 2 days shifted to past. Date of packed config files is correct (in fact update.ver is RAR archive containing also update.ver file but text
formated (BTW screwed idea!).
As result update.ver stops to propagate to ESET products. I did not check all versions but at mimimum V5 and V6 products are afected.
ESET products will not update until someone fixes timestamp or until file date goes over last downloaded file with correct date (2 days!!).
Because updates directories structure (also very crazy - each release does have new numbered directory - big proxy bandwith waste), there will be names inconsitence which can can cause error 1106 on ESET client.
temporary solution:
====================
clear all caches in path (Antivir, PROXY servers)
Because in past I made actualization scripts (before ESET released own) I have lot of experience with this vasting and unreliable schema :-(
-
Most of long time users of Firewall included ESET Products know this bug. I got it again on just freshly installed W81 HP Notebook, almost no software, no HP crapware. After few days of usage of EES latest version BUG saluted me
"HI dear friend, I never die, I am eternal!!!".
So let me ask, is writing simple flat table of rules as complex task?
Sincerely long time Eset partner, more and more sad....
-
NOT FIXED YET?!Lot of time from reporting problem. ESET Support confirmed that it is fixedin module update in V7 and V8. But still no fix in V5. May be special carefor bussines version??Let me remind that BUG IS DESTRUCTIVE. Developers made fix. But somwhwere in ESET releaseprocesses something screeches.BUG crashes PC. Even worse - source of crash - ESET module is hidden.PLEASE if you can URGE release of Internet module V1167 or newer!!!So if anybody have problem with Thinderbird/whole PC crash which disapearsafter switching IMAP/ESET filter off, let know, that this problem is repairedbut not released (in V5) more than month!!!.BTW I found corelation ot this with nonlatin alphabets mails (cyrillic, korean).
-
May be its typo? Latest Pre module available in update servers seems to be 1167, not 1177. It seems switching to Test release solved problem, but may be it disapeared because uncommon message which crashes EES IMAP filter was deleted. As I mentioned - crash apeared about three times in last month...on two different machines. My theory is that source of crash is on messages with cyrilic encoding, but I am not sure. We receive russian messages rarely mostly as spam...
But even if Test solves problem, is it safe to switch to test updates whole company? We are upset because problem is heavy destructive - crash of whole PC every start of Thunderbird until manual msg remove... Test release is test - so may be there is some risk to use it until offical fixed reelase. I got no info from ESET support yet about planned stable release for this module....
-
I got exactly same problem on one user installation.
It seems ESET mail body parser corrupts its data structures and from some point corrupts body request and Thunderbirs falls to infinite loop with more and more allocated memory with nested body request (instead of skipping of failed message)...
It was very hard to catch, because users PC allways crashed on memory exhausted by Thuderbird (it gots all of 2GB RAM memory at about 1 minute)....I was not there on it and after restart all worked, until user tries to get malformed message. So it tooks several weeks, with lot of stress!!!
Config:
Win7CZ all patches,
EES 5.0.2237.1 actual modules and DB
Thunderbird 31.4.0
Internet protection module: 1164 (20141111). (latest for Bussines V5)
I am able to catch malformed message from IMAP server and send it to ESET team with Wireshark catch of whole communication...
But it is visible that ESET IMAP filters corrupt msg header from server, which is rejected by Thunerbird:
19 UID fetch 67367 (UID RFC822.SIZE BODY.PEEK[]>)
19 BAD Junk after body section
19 UID fetch 67367 (UID RFC822.SIZE BODY.PEEK[]>)
19 BAD Junk after body section
19 UID fetch 67367 (UID RFC822.SIZE BODY.PEEK[]>)
19 BAD Junk after body section
... inifinitely....
After switching ESET IMAP filter off I will get succesfuly all messages.Header for this one msg looks this way:19 UID fetch 67367 (UID RFC822.SIZE BODY.PEEK[]<0.65536>)* 1109 FETCH (UID 67367 RFC822.SIZE 200579 BODY[]<0> {65536}So it is visible that range of first chunk of msg body "<0.65536>" is choked by ESET IMAP filter and it leaves ">"!!!Thunderbird repeats this request (same way crippled) until it allocates all memory and crashes OS...Header of this message fetched several commands before (cyrillic encoded!!):
* 1109 FETCH (FLAGS () UID 67367 RFC822.SIZE 200579 BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Reply-To)] {397}Message-ID: <323781D2D90D2FBC60652C9206598A9E@gsmebel>From: =?windows-1251?B?0uDy/P/t4CDe8Pzl4u3g?= <kznamya@etm.ru>To: =?windows-1251?B?wOfg7ODy7uLgIND78erz6/w=?= <vip-art@amber.ru>Subject: =?windows-1251?B?z/Du4evl7Psg7/DoIOLi7uTlIO7h+uXq8uA=?=Date: Mon, 16 Feb 2015 17:24:51 +0300Content-Type: multipart/mixed;boundary="----=_NextPart_000_1339_01D04A0D.78CDFC20"X-Priority: 3May be something messed ESET IMAP parser????
Proper Solution of fixing problem with invalid certificate chain for NodeJS apps.
in ESET Endpoint Products
Posted
Thanks for info, I got little messy feedback from customers about problematic versions. But if I understand, fix simply reverts NODEJS to exclusion of TLS check? So state will be not optimal for javascript security, So some help for manual config accommodation will help I hope. I recommended switching on explicit check of node.exe, but we not yet tested slowdown penalty for data heavy applications...