How to solve cloud defense CRITICAL SEVERITY from pom,xml - security

CRITICAL - org.yaml:snakeyaml - Improper Input Validation
VULNERABILITY
CRITICAL
CWE-20
CVE-2022-1471
CVSS
9.8
Introduced through: org.yaml:snakeyaml :1.27
Discovered on: Dec 1, 2022, 11:15 AM
License(s): Apache-2.0
Exploit: 3.9
Fixed in: Not fixed
Remediation: is not available
SnakeYaml's Constructor() class does not restrict types which can be instantiated during deserialization. Deserializing yaml content provided by an attacker can lead to remote code execution. We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization.
I searched on internet but not got any right solution. i'm getting this cloud defense CRITICAL SEVERITY. so want help in that how we resolved it.

Related

Could not get HttpClient cache - No ThreadContext available for thread id=1

I'm working on upgrading our service to use 3.63.0 (upgrading from 3.57.0) and I've noticed the following warning (with stack trace) shows up in the logs that wasn't there on the previous version:
2022-02-18 14:03:41.038 WARN 1088 --- [ main] c.s.c.s.c.c.AbstractHttpClientCache : Could not get HttpClient cache.
com.sap.cloud.sdk.cloudplatform.thread.exception.ThreadContextAccessException: No ThreadContext available for thread id=1.
at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.lambda$tryGetCurrentContext$0(ThreadLocalThreadContextFacade.java:39) ~[cloudplatform-core-3.63.0.jar:na]
at io.vavr.Value.toTry(Value.java:1414) ~[vavr-0.10.4.jar:na]
at com.sap.cloud.sdk.cloudplatform.thread.ThreadLocalThreadContextFacade.tryGetCurrentContext(ThreadLocalThreadContextFacade.java:37) ~[cloudplatform-core-3.63.0.jar:na]
at io.vavr.control.Try.flatMapTry(Try.java:490) ~[vavr-0.10.4.jar:na]
at io.vavr.control.Try.flatMap(Try.java:472) ~[vavr-0.10.4.jar:na]
at com.sap.cloud.sdk.cloudplatform.thread.ThreadContextAccessor.tryGetCurrentContext(ThreadContextAccessor.java:84) ~[cloudplatform-core-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.RequestScopedHttpClientCache.getCache(RequestScopedHttpClientCache.java:28) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetOrCreateHttpClient(AbstractHttpClientCache.java:78) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.AbstractHttpClientCache.tryGetHttpClient(AbstractHttpClientCache.java:46) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.tryGetHttpClient(HttpClientAccessor.java:153) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor.getHttpClient(HttpClientAccessor.java:131) ~[cloudplatform-connectivity-3.63.0.jar:na]
at com.octanner.mca.service.MarketingCloudApiContactService.uploadContacts(MarketingCloudApiContactService.java:138) ~[classes/:na]
...
This happens when the following calls are made...
Using the lower level API
HttpClient httpClient = HttpClientAccessor.getHttpClient(destination); // warning happens here
ODataRequestResultMultipartGeneric batchResult = requestBatch.execute(httpClient);
Using the higher level API
service
.getAllContactOriginData()
.withQueryParameter("$expand", "AdditionalIDs")
.top(size)
.filter(filter)
.executeRequest(destination)); // warning happens here
Even though this warning shows up in the logs the service requests do continue to work as expected. It's just a little concerning to see this and I'm wondering if maybe I have something misconfigured. I reviewed all of the java docs and the troubleshooting page and didn't see anything out of the ordinary other than how I am fetching my destination, but even using the DestinationAccessor didn't seem to make a difference. Also, I'm not doing any asynchronous or multi-tenant processing.
Any help you or guidance you can give on this would be appreciated!
Cheers!
Such an issue is often the result of missing Spring Boot annotations - especially in synchronous executions.
Please refer to our documentation to learn more about the SAP Cloud SDK Spring Boot integration.
Edit Feb. 28th 2022
It is safe to ignore the logged warning if your application does not need any of the SAP Cloud SDK's multitenancy features.
Error Cause
The SAP Cloud SDK for Java recently (in version 3.63.0) introduced a change to the thread propagation behavior of the HttpClientCache.
With that change, we also adapted the logging in case the propagation didn't work as expected - this is often caused by not using the ThreadContextExecutor for wrapping asynchronous operations.
This is the reason for logs like the one described by the issue author.
Planned Mitigation
In the meanwhile, we realized that these WARN logs are causing confusion on the consumer side.
We are working on improving the situation by degrading the log level to INFO for the message and to DEBUG for the exception.

Hyperledger Fabric: Channel configuration has no channels defined

I got to the project that is based on BYFN sample, but limited to one organization only.
In the app when I call following code:
private Contract getContract(Gateway gw) {
return gw.getNetwork("mychannel").getContract("realchain");
}
following error is produced:
2019-10-30 09:34:51.433 INFO 23108 --- [nio-8080-exec-3] org.hyperledger.fabric.gateway.Gateway : Unable to load channel configuration from connection profile:
org.hyperledger.fabric.sdk.exception.NetworkConfigurationException: Channel configuration has no channels defined.
at org.hyperledger.fabric.sdk.NetworkConfig.loadChannel(NetworkConfig.java:519) ~[fabric-sdk-java-1.4.5-20190620.151745-1.jar:na]
at org.hyperledger.fabric.sdk.HFClient.loadChannelFromConfig(HFClient.java:161) ~[fabric-sdk-java-1.4.5-20190620.151745-1.jar:na]
at org.hyperledger.fabric.gateway.impl.GatewayImpl.getNetwork(GatewayImpl.java:258) ~[fabric-gateway-java-1.4.0-20191002.055106-31.jar:na]
...
...the app recovers somehow itself, but I suspect this error to slow down the whole interaction with the ledger.
Also I'd love to keep my logs clean from any exceptions if possible.
Anyone encountered and resolved the same error?
That is normal behaviour. If the connection profile does not contain a channel definition then the client uses peer definitions (currently for your client identity's organisation only) and assumes the channel exists for those peers. It should not impact performance at all.
You have the option of adding a channel definition to the connection profile, which will avoid this log message occurring, but we wanted to avoid this being necessary.
I agree that the exception appearing in the log gives the false impression that a real error has occurred and I have removed that in the current development code.

TeamCity Build Agent name is not picked up from config file

I have recently setup a VM on azure to use as my build agent.
When the agent is started its name is calculated based on the azure instance name (_myservername) and the name I provide in the buildAgent.properties file is ignored completely.
This is particularly problematic when I have a second agent and the same name is chosen which will result in name conflict.
looking at the teamcity-agent.log I can see the following lines:
[2016-07-14 15:33:04,745] WARN - ds.azure.AzurePropertiesReader - Unable to set self port. Azure integration will experience problems
[2016-07-14 15:33:04,745] INFO - ds.azure.AzurePropertiesReader - Added alternative address is set to
[2016-07-14 15:33:04,745] INFO - ds.azure.AzurePropertiesReader - Instance name and agent name are set to _myservername
...
Question is:
Why is the name I provide via config file is not taking precedence over any other place it reads the name from? -- should it?
How can I possibly force a name on it?
OK, the came to find the answer to this and would share it here in case it would be useful for the humans of the future!
The issue was caused by the the azure-plugin where it was setting a configuration-parameter on the agent called instance name.
https://github.com/JetBrains/teamcity-azure-plugin/issues/17
The issue is fixed in the latest version of the plugin so upgrading it solved my problem. :)

how to resolve warnings when running BLC?

I get following warnings when I try to run BLC demo application. Although there is no known issue caused by these warnings but I would like to know how can I resolve these warnings?
[ WARN] 23:05:05 MergePersistenceUnitManager - A BroadleafClassTransformer is configured for this persistence unit, but Spring reported a problem (likely that a LoadTimeWeaver is not registered). As a result, the Broadleaf Commerce ClassTransformer (org.broadleafcommerce.common.extensibility.jpa.copy.DirectCopyClassTransformer) is not being registered with the persistence unit.
[ WARN] 23:05:05 MergePersistenceUnitManager - A BroadleafClassTransformer is configured for this persistence unit, but Spring reported a problem (likely that a LoadTimeWeaver is not registered). As a result, the Broadleaf Commerce ClassTransformer (org.broadleafcommerce.common.extensibility.jpa.convert.EntityMarkerClassTransformer) is not being registered with the persistence unit.
[ WARN] 23:05:05 MergePersistenceUnitManager - A BroadleafClassTransformer is configured for this persistence unit, but Spring reported a problem (likely that a LoadTimeWeaver is not registered). As a result, the Broadleaf Commerce ClassTransformer (org.broadleafcommerce.common.extensibility.jpa.copy.DirectCopyClassTransformer) is not being registered with the persistence unit.
[ WARN] 23:05:13 AbstractEhcacheRegionFactory - HHH020003: Could not find a specific ehcache configuration for cache named [blSandBoxElements]; using defaults.
[ WARN] 23:05:29 DefaultFilterChainValidator - Possible error: Filters at position 12 and 13 are both instances of org.springframework.security.web.access.intercept.FilterSecurityInterceptor
You need to add -javaagent:/path/of/spring-instrument.jar into your Tomcat or any server VM args.
It has everything to do with spring instrument when coming from BroadleafCommerce
may be you need to add "-javaagent:spring-instrument-3.2.2.RELEASE.jar" into vm args.

XBAP, Fulltrust application security / trust exception

There are alot of settings in all the versions of IE & windows, that may cause problems for users attempting to run xbap applications, particulary in fulltrust mode.
I seem to have gathered a long list of such cases during the last year.
However I'm pussled by this one exception, which occurs on a user on one of my systems, and was hoping that maybe someone here could point me in the right direction.
This application runs on all the used version of windows, and IE6 -> IE9, without problems so there is nothing wrong with the deployment/xbap it self.
The user gets the errorlog / stacktrace below. Have anyone of you encountered this vague trace, and know what the issue might be? This user is running IE8 & W7.
The user have the proper certificates installed in trusted root authorities & trusted publishers. The site in question has been added to list of trusted sites. Xbap has been enabled in IE.
URLs, publickeys, appname etc have been scrambeled.
Brgds,
Stian
PLATFORM VERSION INFO
Windows : 6.1.7600.0 (Win32NT)
Common Language Runtime : 2.0.50727.4963
System.Deployment.dll : 2.0.50727.4927 (NetFXspW7.050727-4900)
mscorwks.dll : 2.0.50727.4963 (win7RTMGDR.050727-4900)
dfshim.dll : 4.0.31106.0 (Main.031106-0000)
SOURCES
Deployment url : http://someurl/someapplication.xbap
Application url : http://someurl/Application%20Files/someapplication_1_0_0_29/someapplication.exe.manifest
IDENTITIES
Deployment Identity : someapplication.app, Version=1.0.0.29, Culture=neutral, PublicKeyToken=sometoken, processorArchitecture=msil
Application Identity : someapplication, Version=1.0.0.29, Culture=neutral, PublicKeyToken=sometoken, processorArchitecture=msil, type=win32
APPLICATION SUMMARY
* Online only application.
* Browser-hosted application.
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* An exception occurred while determining trust. Following failure messages were detected:
+ User has refused to grant required permissions to the application.
* An exception occurred while downloading the application. Following failure messages were detected:
+ The AssertApplicationRequirements method failed. The application cannot be committed.
COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.
WARNINGS
There were no warnings during this operation.
OPERATION PROGRESS STATUS
No phase information is available.
ERROR DETAILS
Following errors were detected during this operation.
* [01/11/2011 09:16:02] System.Deployment.Application.TrustNotGrantedException (Unknown subtype)
- User has refused to grant required permissions to the application.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.ApplicationTrust.RequestTrust(SubscriptionState subState, Boolean isShellVisible, Boolean isUpdate, ActivationContext actCtx, TrustManagerContext tmc)
at System.Deployment.Application.DeploymentManager.DetermineTrustCore(Boolean blocking, TrustParams tp)
at System.Deployment.Application.DeploymentManager.DetermineTrust(TrustParams trustParams)
at System.Deployment.Application.InPlaceHostingManager.AssertApplicationRequirements(Boolean grantApplicationTrust)
at System.Deployment.Application.InPlaceHostingManager.AssertApplicationRequirements()
at MS.Internal.AppModel.XappLauncherApp.AssertApplicationRequirementsAsync(Object unused)
* [01/11/2011 09:16:37] System.Deployment.Application.DeploymentException (Unknown subtype)
- The AssertApplicationRequirements method failed. The application cannot be committed.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.DeploymentManager.WaitForAssertApplicationRequirements()
at System.Deployment.Application.DeploymentManager.SynchronizeCore(Boolean blocking)
at System.Deployment.Application.DeploymentManager.SynchronizeAsyncWorker()
COMPONENT STORE TRANSACTION DETAILS
No transaction information is available.
I should have answered this one when I "solved" the issue.
In the case above there was an issue with the client computer, a change of disk, re-install of OS etc solved the trick.
What the issue was, remains a mystery ;)

Resources