Payara Server 5.2020.4 Trojan:Script/Oneeva.A!ml - payara

I just faced off an strange event when I tried to download the lastest Payara Server Community Full Edition (5.2020.4) on Payara website or on maven: Windows Defender made a trojan alert.
The detected threat is Trojan:Script/Oneeva.A!ml on the payara-5.2020.4.zip file.
I haven't the issue on multi-language or older version.
Have you any info about that?

It looks much like a false positive. I tried running Windows Defender against Payara 5.2020.4 on my computer and it also claimed it detected the same threat, on the file glassfish/modules/war-util.jar in the ZIP. However, it doesn't detect any threat on 5.2020.3. I uploaded the Payara zip with the detected thread to https://www.virustotal.com/gui/home/upload and it shows that no virus scanning engine reports the ZIP as infected. Then I unpacked the war-util.jar from Payara ZIP and ran Windows Defender scan on it, and WD reported 44 files scanned and no threat. So evidently it's a false alarm and WD doesn't go into the file to confirm it really contains threats.
There are people on the internet that also came across Windows Defender detecting the same threat for other file, sometimes even files they created with a serious software, like a spreadsheet created in MS Excel. All of those look like false positives.
One particular case, for example (described here: https://answers.microsoft.com/en-us/windows/forum/all/trojanscriptoneevaaml/1a76e5c3-3ac4-4aea-a37d-51c2a1b40a17?page=3):
excel file used daily for many years
no other detection for this specific infection
detection is designated as an "!ml" (e.g. Machine Learning) type, which is AI based (not signature)
In another case, a user was running Norton A/V, which didn't report any threat. When stopped Norton A/V to update Windows Defender, WD detected this threat immediately on a file that was also previously scanned by Norton A/V without any threat detected.

Related

How can i generate windows certificate so my msi doesn't shows warning to users [duplicate]

This question already has answers here:
How can I stop my installer from triggering Windows 10's "This app has been blocked for your protection" error?
(2 answers)
Closed 3 years ago.
I am new to windows development. I packed my project into a msi setup to install on other systems but when I open the msi in any system it shows a warning as attached . How can I remove this warning?
Note: Be sure to check if your organization already has an EV-level certificate? Just a few emails or phone calls might be wise before trying to research the purchase process?
Trust & Reputation: What you really need is an EV code-signing certificate. Microsoft's SmartScreen feature
in Windows (which is what you see with that blue prompt) is a
reputation-based system where unknown binaries are flagged as unsafe until they are validated safe by users in actual use.
Virustotal.com: An EV code-signing certificate "buys trust outright" - interesting concept - and should allow your users to not see such a prompt even for brand new binaries. Make sure to check all your binaries using virustotal.com though, as many malware-scanner detections can trigger a resurged smartscreen warning for any binary - which is what it is for (signed malware is still malware).
False Positives: False positives for malware is a huge problem since you have to deal with it and solve it, and you can't just tell your users to rebuild their PC and try again.
Moral: The moral of the story is to use Virustotal.com to test for both malware and false positives in your binaries and files for distribution, and to use an EV-level certificate for serious software distribution to get trust for your binaries outright (without delay). An EV-level certificate is not a silver bullet. Problems can still be seen. Trust can be lost too, not just gained (trust... hard to earn, easy to lose).
Tip: A properly signed MSI will also show up with the correct name in the UAC prompt: Installshield Custom Dialogue Installer (see screen shot and then the answer a bit down the page).
The Far Side Perspective: "Be sure that your setup is malware free or an applied digital certificate is proof positive that you delivered the malware" (until that is hackable too) :-)
We do our best.
Link:
How to protect MSI against modification (on malware and false positives - recommended)
How to add publisher in Installshield 2018
How to pass the Windows Defender SmartScreen Protection?

Clearcase corrupting checked out Project files when changing network connection

Is anyone aware of a known issue (and workaround) where it seems like Rational ClearCase will corrupt a Microsoft Project file if it is checked out and the network connection changes? I have a laptop that is docked and hardwired to local network most of the time, and I perform some work with the Project file, then I will undock the laptop to go to a meeting or home for the evening, and upon re-docking, the Project file can no longer be opened and appears corrupt.
The error message shown is "Project cannot open the file. -Check that the file name and path are correct. -Check that the file format is recognized by Project..."
There doesn't seem to be anything directly related to Microsoft Project Server regarding ClearCase on ibm.com.
I have seen issues with dynamic views, when the view server is on the network (and said network is abruptly cut).
If this is your case, I would recommend using snapshot views.
You can have similar issue with ClearTeam 8.x web views (since the latest versions support dynamic views)
Regarding snapshot views (meaning files directly on your hard drive), you only need to watch for concurrent processes that might still access your file when undocking. A program like procmon can help.

Unrecognized database format message on local drive only

I have the following very weird situation:
Access 2003 MDB application together with a SQL server backend
Application runs from local hard drive using Access Runtime viewer 2010 OR Access 2010
Windows 7 PC
On some PC's users get the infamous unrecognized database format message. It happens at some point while using the application, never at startup. After that the only solution is to stop and restart the application. Same effect, it works for a while and then fails.
Running exact the same version from a network drive does not give any issues. Replacing the Runtime Viewer with a full blown Access did not make any difference. On Windows XP we never had this problem.
Any ideas?
I'm assuming you've tried the usual Repair/Compact by now? Any strange outlier behavior like you're describing usually indicates some form of corruption. At times, corruption goes deep and leaves behind artifacts that can never get resolved. You may want to create a fresh, new DB and import all of the forms/reports/queries/etc... into the fresh DB. This has fixed many issues similar to yours that I've encountered over the years.

VB6 Application Creating Files under "Program Files" in Vista or later OS

I have a legacy VB6 system which is installed in C:/Program Files/IronDuke
In the past it has written some files into this directory. I understand that these files are hidden away if the application is installed under Vista or a later OS, but not if they were written under XP or earlier OS.
How can I retrieve a copy of these 'hidden' files when written under Vista or Windows 7 or 8?
You are looking at a feature called UAC Virtualization, this blog posting gives a pretty good rundown on what is happening and where the files are located.
From above article:
For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini. If an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ in the registry, it will automatically be redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.
so in your case if you are trying to find the files you need to look in:
C:\Users\Username\AppData\Local\VirtualStore\Program Files\IronDuke\
You cannot write to Program Files under Windows 7 / 8 - system security prevents programs running as regular users from doing so. One option for you is to write these files to the user's profile folder (you'll have to update the VB6 program for this, although the changes should be pretty small if the program is otherwise well-written). This would be your best option since the updated code would work well in the future without more changes.
You amy be able to get the program running using Compatibility Mode but I doubt it - on my Windows 8 system I don't even get 'Windows XP' as a compatibility option anymore. All other options will likely enforce security.
You can try running your program as administrator but I'd only do this if you don't have the source to make the changes - it's poor practice to run programs with all privileges since it opens up the system for attacks.

Database errors in Quantum Grid demos in Delphi XE Professional

Whenever I open one of the Quantum Grid demos in Delphi XE Pro (on Windows 7 32-bit), the following error is displayed for every table (I think) in the project:
error message http://www.tranglos.com/img/qgerror.png
The message is:
Network initialization failed.
File or directory does not exist.
File: C:\PDOXUSRS.NET
Permission denied.
Directory: C:\.
I understand permission issues writing to c:\, but the result is that while I can build and run the demo projects, no data is displayed, which makes the demos rather useless. And what kind of database writes its configuration to c:\ directory in the 21st century anyway? :) (Yes, I know very little about Paradox databases, but I won't ever be using one either. I just want to learn how to use the grid.)
Using BDE Administrator I've tried changing the Paradox "NET DIR" value to a folder with write permissions on the C drive. Result: now the database tables cannot find their data:
Path not found.
File: C:..\..\Data\GENRES.DB.
...and the unhelpfully truncated path gives no indication where the files are expected to be.
Is there a way to work around the problem so that the demos can load their sample data correctly?
Did you install the BDE correctly? It should use the DBDEMOS files. Do you see such an alias in the BDE administration utility? Can you open that database in one of the Delphi demos?
The BDE is not a XXI century database, it was developed twenty years ago and never upgraded lately. It's an obsolete tecnology, but because it comes still with every release of Delphi with a known database it is still often used in demos because nothing new has to be installed.
Anyway that file is not its configuration file. It's a sharing lock file to allow more than one user to use the database concurrently. Because it is a file based database without a central server, it has to use such kind of shared files. Usually its position is changed to a network share, but it defaults to C:\ for historical reasons.
Anyway it's not only the BDE still attempting to write in the prong directories. I still see a full bunch of applications attempting to write to C:\ (especially logs) or other read-only positions.
Using BDE Admin to change the location for PDOXUSRS.NET helped, but it wasn't sufficient. DevExpress did the right thing in specifying a relative folder for the data location, and the relative folder seems perfectly allright, but for some reason the DB can't find it.
Solution: under the \Demos\ folder find all the *.dfm files that contain the string
..\..\Data
and replace that string with the absolute path to the demos folder. That done, all the demos open correctly.
I know this message from our own applications. It has to do with security measures introduced with Windows Vista. The operating system trying to protect critical files denies access to them. There is a method how to bypass this mechanism without compromising security. Try to run your application in compatibility mode. When application is running in compatibility mode, read / write operations from / to system folders are redirected to "safe" directories located in C:\Users[Current User]\AppData\Local\VirtualStore.
More info on http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html.

Resources