by Contributed | Nov 29, 2021 | Technology
This article is contributed. See the original author and article here.
This fall, we released Decoding NOBELIUM, a four-part video series that pulls back the curtain on the world of threat detection and showcases the incredible efforts and insights from defenders who responded to the most sophisticated nation-state attack in history. Since we first started sharing information on this extremely advanced threat actor group in December 2020, we have only continued to see an increase in nation-state activity.
In this blog, we’ll share some of the insights that we heard from leading cybersecurity experts while filming the Decoding NOBELIUM series that you can use to help your own organization better prepare for advanced attacks. This guidance is grounded in real-world examples and not only applies to defending against advanced adversaries but will also strengthen your security posture against more common threats like phishing, email compromise, ransomware, and more. Let’s dive in.
Defending against nation-state actors
Nation-state actors are persistent, well-funded, and exceptionally skilled at reconnaissance. In practice, this means they’re very good at finding the gaps in security—whether that be exploiting an identity with high-level access, a port into the network that is left open, or an app from a trusted software provider by injecting malicious code.
Start with a strong foundation—Zero Trust
While there are many individual things that can be done to protect your organization against these advanced adversaries, one of the most critical components is to ensure you have a robust Zero Trust strategy and are working on applying its guiding principles broadly. Zero Trust helps with both the prevention of and detection and response of a breach. In the case of the SolarWinds compromise, organizations that had applied micro-segmentation to their infrastructure were much more effective at limiting the damage of compromised software being inside the corporate firewall.
Advanced adversaries like NOBELIUM will exploit virtually any gap they can find—so a comprehensive deployment is critical. Organizations that embrace Zero Trust are more prepared for defending against sophisticated threats because their security foundations and baselines are stronger. Adopting Zero Trust requirements like verifying identities explicitly and enforcing least privileged access dramatically reduce the impact of breaches—and in some cases, even prevent it. For example, one of the ways NOBELIUM succeeded was by targeting and compromising highly privileged vendor accounts that lacked protections such as multifactor authentication (MFA), access policy restrictions, or device compliance. By enforcing conditional access policies for all users, organizations are significantly more resilient against account compromise.
“And the Zero Trust principles around identity are really about ensuring you have strong identity, so you know who is accessing something, from what device or endpoint, and that it is strongly authenticated against what service and where. You have areas of risk because you’re not able to get the strength of the identity or authentication as you want, so you have to limit or have conditional access so you can manage your risk proportional to the situation. So those principles a very important for customers to go fully embrace and modernize their identity infrastructure.” – John Lambert, General Manager, Microsoft Security Threat Intelligence Center
To learn about Microsoft’s approach to Zero Trust by checking out the updated maturity model and architecture shared earlier this month. And for technical guidance and resources on implementing Zero Trust across your entire digital environment, check out the Zero Trust Guidance Center.
Focus on cyber-hygiene
While many nation-state attacks make headlines for sophisticated attack chains and zero-day vulnerabilities, these sophisticated actors prefer to use the lowest cost, highest impact tactics they can in order to accomplish their objectives. This means, more often than not, they’re using very common tactics, techniques, and procedures (TTPs)—such as remotely accessing systems with accounts not protected by MFA or taking advantage of known vulnerabilities on unpatched systems. We can’t understate how important it is to get the fundamentals right. According to our annual report, basic cyber-hygiene protects against 98% of attacks.
“It’s too often that nation-states don’t need advanced sophisticated tactics like we saw.” – Cristin Goodwin, General Manager, Microsoft Digital Security Unit
Fortunately, strong cyber-hygiene can dramatically increase the cost to attackers—making them more likely to move on or take riskier actions that are easier to detect.
“Keeping up with patches on your operating system, your workstations, your middleware tier, your web applications, all of those things are really important to ensure that you’re maintaining a base level of security because those are already known issues that hackers are going to exploit and specific things to that effect.“ – Dave Kennedy, CEO and Founder, TrustedSec and Binary Defense
Make sure you’re enabling MFA, applying least privilege access, keeping your software up to date, utilizing antimalware broadly, and implementing best practices like applying sensitivity labels and data loss prevention policies to protect your data. Read the report for our full list of recommendations based on what we’re seeing is most effective at defending against today’s threat landscape.
Protect your identities
“The attacks of the future, a lot of them are going to be identity based. Once I can authenticate into your environment, I don’t need malware anymore.” – Roberto, Principal Consultant and Lead Investigator, Microsoft Detection and Response Team
Increasingly, major security incidents start with just one compromised account—whether through phishing, password spraying, or purchasing paired user-names and passwords on the dark web. Once attackers get their foot inside the perimeter, they can more easily escalate their privileges or gather intelligence that helps them reach their objectives. Protecting identities is twofold: First, we need to make it harder to steal an identity; second, we need to make it easier to detect accounts that have been compromised.
Fortunately, there are some simple actions we can take to dramatically reduce the risk of compromised accounts. Enforcing MFA can prevent up to 99.9% of account compromise attacks. Blocking legacy authentication protocols like POP, SMTP, IMAP, and MAPI that can’t enforce MFA will also help drastically reduce your attack surface area. As you build out your program, make sure to prioritize privileged accounts, which are often the top target for attackers.
To help make it easier to detect a compromised user, Microsoft’s defenders recommend making sure you’re using user and entities behavioral analytics (UEBA). This allows your organization to build a baseline of how your users and devices behave, making it much easier to identify anomalous behavior.
“Identity is the number one entry in access point for the majority of all of these attacks, and if you can get a handle on identity first, then your journey towards being secure is going to be immensely faster and more efficient.” – Elizabeth Stephens, Chief of Staff, Microsoft 365 Security
Check out the blog, Prevent and detect more identity-based attacks with Azure Active Directory, by my colleagues Kristina and Sarah for more information on how to protect your identities.
Use secure devices for critical tasks
Security experts recommend protecting privileged accounts in order to secure access to highly-sensitive data. However, that alone isn’t enough protection—for example, an adversary can attack a device directly. The shift to remote work has increased the adoption of accessible Remote Desktop Protocol (RDP), and there’s now an abundance of RDP ports and protocols publicly exposed to the internet for attackers to gain access using a brute force attack to compromise accounts. To add another layer of defense for your critical data, they strongly advise securing those originating devices.
“If you [Remote] Desktop Protocol into a box, don’t leave the session open when you leave. Close the session, ’cause then they can’t just grab your session and start using your login.” – Joanne, Security Analyst, Microsoft DSR Security Operations Center HUNT Team
Joanne also recommends taking a few more steps to help protect your devices and most-sensitive data:
“…You want to use a secure networking device. You don’t want to use your everyday workstation or everyday desktop to do administrative tasks on sensitive systems. You want to have a separate system…a System Administrator Workstation (SAW). You want to have some kind of SAW device to do your administrative tasks from.” – Joanne, Security Analyst, Microsoft DSR Security Operations Center HUNT Team
Learn about how we use SAWs at Microsoft to protect our own environment. And to learn more about the requirements of SAWs and how to deploy the security controls to secure a workstation for sensitive users, check out our documentation.
Implement robust monitoring systems and build a baseline of your environment
“This incident showed the attackers will leverage very different parts of an environment, both in the cloud and on-prem, to achieve what they want.” – Pete, Senior Software Engineer, Microsoft Threat Intelligence Center
Today’s environments offer plenty of places for attackers to hide in the shadows, so it’s become critical to identify attacker behavior more effectively. While prevention is critical, many organizations need to further strengthen their detection and response capabilities. To get started, ensure your security team has the right tools in place for an accurate and fast response. For example, today’s robust security analytics systems can help correlate seemingly individual events across multiple domains into a single view of an attacker’s kill chain.
“In order to respond to an attack like NOBELIUM, with its scope and breadth and sophistication, you really need to have visibility into various entities across your entire digital state. So you need to have visibility into security data and events relating to users, endpoints, and infrastructure whether on-prem or in the cloud” – Sarah Fender, Partner Product Manager, Microsoft Azure Sentinel
There are quite a few different approaches and solutions out there to help your organization tackle this challenge. Our experts recommend taking a holistic, integrated approach to avoid fragmentation. Microsoft offers a solution that combines our cloud-based SIEM, Azure Sentinel, along with our XDR technologies, including Microsoft 365 Defender, to provide an automated approach to threat detection and response across the entire environment. Check out a Mechanics Video with Rob Lefferts to see how this combination can help organizations respond quickly to an attacker like NOBELIUM.
Plan your response and practice
And it’s not just about technology—organizations need a comprehensive incident response plan and a well-trained team at the ready.
“Supply chain threats really reinforce how important it is to know what’s in your environment and be able to manage it, and then critically have a backup plan. It’s that it’s not a matter of if, it’s when. And you want to have responders that are well-practiced at these incidents and able to respond some things that help them in response.” – John Lambert, General Manager, Microsoft Security Threat Intelligence Center
In a recent study, Microsoft conducted, 39% of CISOs report having little to no incident planning in place. The NOBELIUM attack really reinforced the importance of having a robust plan, team, and set of capabilities in place during a large-scale attack. We found that organizations that were prepared responded more quickly, limiting the damage and keeping the business running. Additionally, a 2021 Ponemon study, Cost of a Data Breach Report 2021, found that organizations without a meaningful incident response team and plan in place saw the cost of their breach go up by 55%.
Preparation should also extend beyond planning to include real-world practice and testing of your defenses. This will help ensure not only that your security team is prepared to execute the response plan effectively, but that plans are effective and any weaknesses are discovered and addressed before the real attack happens.
“Given some of our findings and some of our takeaways from this attack, investing in penetration testing, investing in putting together teams and practice[ing].” Ramin, Senior Malware Reverse Engineer, Microsoft Threat Intelligence Center
Check out our documentation on conducting pen testing in Microsoft Azure and running attack simulations in Microsoft 365 to begin tests in your own environment.
Additional resources and next steps
Microsoft is committed to helping organizations stay protected from cyberattacks, whether cybercriminal or nation-state by utilizing our leading threat intelligence and global team of dedicated cybersecurity defenders to combat global threats. Just two recent examples of Microsoft’s efforts to combat nation-state attacks include a September 2021 discovery and investigation of a NOBELIUM malware referred to as FoggyWeb and our May 2021 profiling of NOBELIUM’s early-stage toolset compromising EnvyScout, BoomBox, NativeZone, and VaporRage.
If you’re interested in learning more about how Microsoft defenders and industry partners respond to nation-state attacks, check out the full Decoding NOBELIUM series where you’ll gain insights and learn critical steps to improve your security posture against the next wave of attacks.
For more information on cyberattacks, whether cybercriminals or nation-state, check out the Microsoft Security Response Center.
by Contributed | Nov 29, 2021 | Technology
This article is contributed. See the original author and article here.
I had a customer streaming messages at a high-rate (up to 2000 msg/s – 1KB each) from a protocol translator running on an x86 industrial PC to a cloud-based Mosquito MQTT broker.
That edge device evolved quickly into a more capable and secure intelligent edge solution thanks to Azure IoT Edge and Azure IoT Hub, adding device provisioning (secured with an HW-based identity) and device management capabilities on top of a bi-directional communication, along with the deployment, execution, and monitoring of other edge workloads in addition to a containerized version of the original MQTT protocol translator.
The performance requirement did not change though: the protocol translator (running now as an Azure IoT Edge module) still had to ingest and deliver to the IoT Hub up to 2000 msg/s (1KB each), with a minimum latency.
Is it feasible? Can an IoT Edge solution stream 2000 msg/s or even higher rates? What’s the upper limit? How to minimize the latency?
This blog post will guide you through a detailed analysis of the pitfalls and bottlenecks when dealing with high-rate streams, to eventually show you how to optimize your IoT Edge solution and meet and exceed your performance requirements in terms of rate, throughput, and latency.
Topics covered:
The message queue
The Azure IoT Edge runtime includes a module named edgeHub, acting as a local proxy for the IoT Hub and as a message broker for the connected devices and modules.
The edgeHub supports extended offline operation: if the connection to the IoT Hub is lost, edgeHub saves messages and twin updates in a local message queue (aka “store&forward” queue). Once the connection is re-established, it synchronizes all the data with the IoT Hub.
The environment variable “UsePersistentStorage” controls whether the message queue is:
- stored in-memory (UsePersistentStorage=false)
- persisted on disk (UsePersistentStorage=true, which is the default
When persisted on disk (default), the location of the queue will be:
- the path you specified in the edgeHub HostConfig options in the deployment manifest as per here
- …or in the Docker’s OVERLAY folder if you didn’t do any explicit bind, which is:
/var/lib/docker/overlay2
The size of the queue is not capped, and it will grow as long as the device has storage capacity.
When dealing with a high message rate over a long period, the queue size could easily exceed the available storage capacity and cause the OS crash.
How to prevent the OS crash?
Binding the edgeHub folder to a dedicated partition, or even a dedicated disk if available, would protect the OS from uncontrolled growth of the edgeHub queue.
If the “DATA” partition (or disk) runs out of space:
- the OS won’t crash…
- …but edgeHub container will crash anyways!
How to prevent the edgeHub crash?
Do size the partition for the worst-case or reduce the Time-To-Live (TTL).
I will let you judge what’s the worst case in your scenario. But the very worst case is total disconnection for the entire TTL. During the TTL (which is 7200 s = 2 hrs. by default), the queue will accumulate all the incoming messages at a given rate and size. And be aware that the edgeHub keeps one queue per endpoint and per priority.
An estimation of the queue size on disk would be:
And if you do the math, a “high” rate of 2000 [msg/s] with 1 [KB/msg] could easily consume almost 15 GBs of storage within 2 hrs.
But even a “low” 100 [msg/s] rate you could easily consume up to 1GB, which would be an issue on constrained devices with an embedded storage of few GBs.
Then, to keep the disk consumption under control:
- the application requirements and what the “worst case” means in your scenario
- do some simple math to estimate the max size consumed by the edgeHub queue and size the partition/disk accordingly…
- …and fine-tune the TTL
If you keep the queue disk consumption under control with proper estimation and sizing, you don’t need to bind it to a dedicated partition/disk. But it’s an extra-precaution that comes with almost no effort.
Btw: If you considered setting UsePersistentStorage=false to store the queue in memory, you may realize now that the amount of RAM needed would make it an expensive option if compared to disk or non-viable at all. Moreover, such an in-memory store would NOT be resilient to unexpected crashes or reboots (as the “EnableNonPersistentStorageBackup” can backup and restore the in-memory queue only when you go through a graceful shutdown and reboot).
The clean-up process
What happens to expired messages?
Expired messages are removed every 30 minutes by default, but you can tune that interval using this environment variable MessageCleanupIntervalSecs:
If you use different priorities (LINK), do set “CheckEntireQueueOnCleanup”=true to force a deep clean-up and make sure that all expired messages are removed, regardless of the priority.
Why? The edgeHub keeps one queue per endpoint and per priority (but not per TTL)
If you have 2 routes with the same endpoint and priority but different TTL, those messages will be put in the same queue. In that case, it is possible that the messages with different TTLs are interleaved in that queue. When the cleanup processor runs, by default, it checks the messages on the head of each queue to see if they are expired. It does not check the entire queue, to keep the cleanup process as light as possible. If you want it to clean up all messages with an expired TTL, you can set the flag CheckEntireQueueOnCleanup to true.
The built-in metrics
Now that you have the disk consumption of your edgeHub queue under control, it’s a good practice to keep it monitored using the edgeAgent and edgeHub built-in metrics and the Azure Monitor integration.
The “edgeAgent_available_disk_space_bytes” reports the amount of space left on the disk.
…but there’s another metric you should pay attention to, which is counting the number of non-expired messages still in the queue (i.e. not delivered yet to the destination endpoint):
That “edgehub_queue_length” is a revelation, and it explains how the latency relates to the rates. But to understand it, we must measure the message rate along the pipeline first.
The analysis
How to measure the rates and the queue length
I developed IotEdgePerf, a simple framework including:
- a transmitter edge module (1), to be deployed on the edge device under test. It will generate a burst of messages and measure the actual output rate (at “A”)
- an ASA query (2), to measure the IoT Hub ingress rate (at “B”) and the end-2-end latency (“A” to “B”)
- a console app (3), to coordinate the entire test, to collect the results from the ASA job and show the stats
Further instructions in the IotEdgePerf GitHub repo.
I deployed the IotEdgePerf transmitter module to an IoT Edge 1.2 (instructions here) running on a DS2-v2 VM and connected to a 1xS3 IoT Hub. I launched the test from the console app as follows:
dotnet run --
--payload-length=1024
--burst-length=50000
--target-rate=2000
Here are the results:
- actual transmitter output rate (at “A”): 1169 msg/s, against the desired 2000 msg/s
- IoT Hub ingestion rate: 591 msg/s (at “B”)
- latency: 42s (“C”)
As anticipated, the “edgehub_queue_length” explains why we have the latency. Let’s have a look at it using Log Analytics:
Let’s correlate the queue length with the transmission burst: as the queue is a FIFO (First-In-First-Out), the last message produced by the transmitter is the last message ingested by the IoT Hub. Looking at “edgehub_queue_length” data, the latency on the last message is 42 seconds.
How does the queue’s growth and degrowth slopes and maximum value relate to the message rate?
- first, during the burst transmission, the queue grows with a rate:
which is in line with what you would expect from a queue, where the growth rate:
- then, once the transmission is over, the queue decreases with a rate:
The consistency among the different measurements (on the message rate, queue growth/degrowth and latency) proves that the methodology and tools are correct.
Minimum latency
Using some simple math, we can express the latency as:
where N is the number of messages.
If we apply that equation to the numbers we measured, again we can get a perfect match:
The latency will be minimum when rateOUT = rateIN, i.e. when the upstream rate equals the source output rate, and the queue does not accumulate messages. This is quite an obvious outcome, but now you have a methodology and tools to measure and relate to each other the rates, the latency, and the queue length (and the disk consumption as well).
Looking for bottlenecks
Let’s go back to the original goal of a sustained 2000 msg/s rate delivered upstream with minimum latency. We are now able to measure both the source output and the upstream rate, and to tell what’s the performance gap we must fill to assure minimum latency:
- the source output rate should increase from 1160 to 2000 msg/s (A)
- the upstream rate should increase from 591 to 2000 msg/s (B)
But… how to fill that gap? What’s the bottleneck? Do I need a faster CPU or more cores? More RAM? Or the networking is the bottleneck? Or are we hitting some throttling limits on the IoT Hub?
Scaling UP the hardware
Let’s try with a more “powerful” hardware.
Even if IoT Edge will usually run on a physical HW, let’s use IoT Edge on an Azure VMs, which provide a convenient way of testing different sizes in a repeatable way and compare the results consistently.
I measured the baseline performance of the DSx v2 VMs (general purpose with premium storage) sending 300K messages 1KB each using IotEdgePerf:
VM SIZE
|
SPECS (vCPU/RAM/SCORE)
|
Source
[msg/s]
|
Upstream
[msg/s]
|
Standard_DS1_v2
|
1 vcpu / 3.5 GB / ~20
|
900 ÷ 1300
|
500 ÷ 600
|
Standard_DS2_v2
|
2 vcpu / 7 GB / ~40
|
Standard_DS3_v2
|
4 vcpu / 7 GB / ~75
|
Standard_DS4_v2
|
8 vcpu / 14 GB / ~140
|
Standard_DS5_v2
|
16 vcpu / 56 GB / ~300
|
(test conditions: 1xS3 IoT Hub unit, this C# transmitter module, 300K msg, msg size 1KB)
Scaling UP from DS1 to DS5, the source rate increases by around ~50% from a DS1 to DS5… which is peanuts if we consider that a DS5 performs ~15x better (scores here) and costs ~16x (prices here) than a DS1.
Even more interestingly, the upstream rate does not increase, suggesting there’s a weak correlation (or no correlation at all) with the HW specs.
Scaling OUT the source
Let’s distribute the source stream across multiple modules in a kind of scaling OUT, and look at the aggregated rate produced by all the modules.
The maximum aggregated source is ~1900 msg/s rate (obtained with N=3 modules), which is higher than the rate of a single module (~1260 msg/s), with a gain of ~50%. However, such improvement is not worth it if we consider the higher complexity of distributing the source stream across multiple source modules.
Interestingly, the upstream rate increases from ~600 to ~1436 msg/s. Why?
The edgeHub can either use the AMQP or the MQTT protocol to communicate upstream with the cloud, independently from protocols used by downstream devices. The AMQP protocol provides multiplexing capabilities that allow the edgeHub for combining multiple downstream logical connections (i.e. the many modules) into a single upstream connection, which is more efficient and leads to the rate improvement that we measured. AMQP is indeed the default upstream protocol and the one I used in this test. This also confirms that the upstream rate is mostly determined by the protocol stack overhead.
Many cores with many modules
Scaling UP from a 1 vCPU machine (DS1) to a 16 vCPU (DS5) machine didn’t help when using a single source module. But what if we have multiple source modules? Would many cores bring an advantage?
Yes. Multiple modules mean multiple docker containers and eventually multiple processes, that will run more efficiently on a multi-core machine.
But is the 3.5x boost worth the 16x price increase of a DS5 vs DS1? No, if you consider that the upstream, again, didn’t increase.
Increasing the message size: from rate to throughput
Let’s go back to a single module and increase the message size from 1 KB to 32 KB on a DS1v2 (1 vcpu, 3.5GB). Here are the results:
(test conditions: 1xS3 IoT Hub unit, this C# transmitter module)
The rate decreases from 839msg/s@1KB down to 227msg/s@32KB, but the THROUGHPUT increases from ~0.8 MB/s up to ~7.2MB/s. Such behavior suggests that sending big messages and at a lower rate is more efficient!
How to leverage it?
Let’s assume that the big 16KB message is a batch of 16 x 1 KB messages: it means that the ~4.5MB/s throughput would be equivalent to a message rate of ~4500 msg/s of 1KB each.
Then message rate and throughput is not the same thing. If the transport protocol (and networking) is the bottleneck, higher throughputs can be achieved by sending bigger messages at a lower rate.
How do we implement message batching then?
Message Batching
We have two options:
- Application-level batching: the batching is done in the source module, whereas the downstream service extracts the original individual messages. This requires custom logic at both ends.
- edgeHub built-in batching: the batching is managed by the edgeHub and the IoT Hub automatically and in a transparent way, without the need for any additional code.
The ENV variable “MaxUpstreamBatchSize” sets the max number of messages EdgeHub will batch together into a single message up to 256KB.
edgeHub built-in batching deep dive
The default is MaxUpstreamBatchSize = 10, meaning that some batching is already happening under the cover, even if you didn’t realize it. The optimal value for MaxUpstreamBatchSize would be 256 KB / size(msg), as you would want to fit as many small messages as you can in the batch message.
How does it work?
Set the edgeHub RuntimeLogLevel to DEBUG and look for lines containing “obtained next batch for endpoint iothub”:
Looking at the timestamps, you’ll see that messages are collected and sent upstream in a batch every 20ms, suggesting that:
- the latency introduced by this built-in batching is negligible (< 20ms)
- this mechanism is effective only when the input rate is > 1/20ms=50 msg/s
Comparison of the batching options
Are the application-level and built-in batching equivalent?
On the UPSTREAM side, you have batch messages (i.e. big and low-rate) in both cases. It means that:
- you pay for the batch size divided by 4KB
- and the batch messages counts as a single d2c operation
The latter point is quite interesting: as the message batch counts as 1 device-to-cloud operation, the batching helps also reduce the pressure on the d2c throttling limit of the IoT Hub, which is an attention point when dealing with high message rates.
On the SOURCE side, the two approaches are very different:
- application-level batching is sending batch messages (i.e. big, and low-rate)
- …while the built-in batching is sending the individual high-rate small messages, and potentially still less efficient (think of the IOPS on the disk for instance, and the transport protocol used to publish the messages to the edgeHub broker).
Eventually, we can state that:
- application-level batching is efficient end-2-end (i.e. source and upstream)…
- …while the built-in batching is efficient on the upstream only
Let’s test that assumption.
Built-in batching performance
On a DS2v2 VM, the max output rate of the source module is ~1100 [msg/s] (with 1KB messages).
As expected, such source rate does not benefit from higher MaxUpstreamBatchSize values, while the upstream does, and it eventually equals the 1100 [msg/s] source rate (hence no latency).
Application-level batching performance
The application-level batching is effective on both the source and upstream throughput.
On a DS1 (1 vCPU, 3.5GB of RAM, which is the smallest size of the DSv2 family) you can achieve:
- a sustained ~3600 [KB/s] end-to-end with no latency (i.e. on both source and upstream) with a msg size of 8KB…
- …while with a msg size of 32KB, you can increase the source throughput up to 7300 [KB/s], but the upstream is capped at around 4200 KB/s. That will cause some latency.
Is latency always a problem? Not actually. As we saw, the latency is proportional to the number of messages sent (N):
When sending a short burst of messages, the latency may be negligible. On the other hand, on short burst you may want to minimize the transmission duration.
As an example, let’s assume you want to send N=1000 messages, of 1 KB each. Depending on the batching, the transmission duration at the source side will be:
- no batching: transmission duration = 1000 / 872 ~ 1.1s (with no latency)
- 8KB batching: transmission duration = 1000 / 3648 ~ 0.3s (with no latency)
- 32KB batching: transmission duration = 1000 / 7328 ~ 0.1s (+0.2s of latency)
Shortening the transmission duration from a 1.1s down to 0.1s could be critical in battery powered applications, or when the device must send some information upon an unexpected loss of power.
Azure IoT Device SDKs performance comparison
The performance results discussed in this blog post were obtained using this C# module, which leverages the .NET Azure IoT Device SDK.
How do other SDKs (Python, Node.js, Java, C) perform in terms of maximum message rate and throughput? The performance gap, if any, would be due to:
- language performance (C is compiled whereas others are interpreted)
- specific SDK architecture and implementation
As an example of the latter, the JAVA SDK differs from other SDKs as the device/module client embeds a queue and a periodic thread that checks for queued messages. Both the thread period (“receivePeriodInMilliseconds”) and the number of messages de-queued per execution (“SetMaxMessagesSentPerThread”) can be tweaked to increase the output rate.
On the other hand, what is the common denominator to all the SDKs? It’s the transport protocol, which ultimately sets the upper bound of the achievable performance. In this blog post we focused on MQTT, and it would be worth to explore the performance upper bound by using a fast and lightweight MQTT client instead of the SDK. That’s doable and it’s explained here.
A performance comparison among the different Device SDKs as well as a MQTT client will be the topic for a next blog post.
Tools
VM provisioning script
A bash script to spin up a VM with Ubuntu Server 18.04 and a fully provisioned Azure IoT Edge ready-to-go: https://github.com/arlotito/vm-iotedge-provision
IotEdgePerf
A framework and a CLI tool to measure the rate, the throughput and end-to-end latency of an Azure IoT Edge device:
https://github.com/arlotito/IotEdgePerf
Conclusion
This blog post provided a detailed analysis of the pitfalls and bottlenecks when dealing with high-rate streams, and showed you how to optimize your IoT Edge solution to meet and exceed your performance requirements in terms of rate, throughput, and latency.
On an Azure DS1v2 Virtual Machine, we were able to meet and exceed the original performance target of 2000 msg/s (1KB each) and minimum latency, and we achieved a sustained end-2-end throughput of 3600 KB/s with no latency, or up to 7300 msg/s (1KB each) with some latency.
With the methodology and tools discussed in this blog post, you can assess the performance baseline on your specific platform and eventually optimize it using the built-in or application-level message batching.
In a nutshell:
- to avoid the OS and edgeHub crash:
- do estimate the maximum queue length and do size the partition/disk accordingly
- adjust the TTL
- keep the queue monitored using the built-in metrics
- measure the baseline performance (rate, throughput, latency) of your platform (using IotEdgePerf) and identify the bottlenecks (source module? Upstream?)
- if the bottleneck is the upstream, leverage the built-in batching by tuning the MaxUpstreamBatchSize
- if the bottleneck is the source module, use application level-batching
- possibly try a different SDK or a low-level MQTT client for maximum performance
Acknowledgements
Special thanks to the Azure IoT Edge team (Venkat Yalla and Varun Puranik), the Industry Solutions team (Simone Banchieri, Stefano Causarano and Franco Salmoiraghi), the IoT CSU (Vitaliy Slepakov and Michiel van Schaik) and Olivier Bloch for the support and the many inspiring conversations.
by Contributed | Nov 29, 2021 | Technology
This article is contributed. See the original author and article here.
Building fast, fluid Microsoft 365 web applications is one of our core focus areas on the SharePoint engineering team. Over the course of this year, we’ve double-downed on performance – making our web apps load faster, delivering up to a 57% improvement in page interactivity, along with the ability to work with data offline. We’re pleased to announce we’ve reached general availability for Microsoft Lists customers. The focus of this article is to share how it all works and how we went about designing and developing it.
We’re pleased to announce that we’ve reached general availability for Microsoft Lists: Fast and offline.
And we didn’t stop there. Our ambition is to deliver experiences that are consistently fast for every user on all kinds of networks and devices – even when there is no connection to the Internet. To help us accomplish this, we looked beyond the fundamentals to unlock new levels of web performance and enable new ways for our customers to experience Microsoft 365 web applications. We do this by blending Progressive Web Apps (PWAs) and expanding Project Nucleus.
The combination of Progressive Web Apps (PWAs) and the expansion of Project Nucleus enables faster Web applications – even when offline.
Transforming Microsoft 365 apps into PWAs
As part of our ongoing effort to improve performance and design new experiences, we began transforming our web applications into Progressive Web Apps (PWAs) starting with Microsoft Lists and OneDrive.
Install Microsoft Lists as a Progressive Web Apps (PWA) from your browser.
PWAs allow us to provide access to open web technologies for cross-platform interoperability. And in turn, you get an app-like experience customized for your devices. They are websites progressively enhanced to function like installed apps. PWAs allow us to combine the best of the web and native apps, like websites with app features: The ability to load offline, run within the local operating system, support push notifications and periodic background updates, access hardware features, and more.
When installed, PWAs are just like other apps on Windows. They can be added to the Start Menu, pinned to the Taskbar, work with files, run on user login, and more.
OneDrive as a PWA running on the Windows desktop.
To build web experiences that load and function offline – including support for editing – we had to look beyond PWAs. Enter Project Nucleus.
It all started as ‘Project Nucleus’
Project Nucleus was the codename behind our initiative of building a new client-side component to supercharge existing web apps, like Microsoft Lists, by providing a consistently fast and smooth experience on all kinds of devices and networks – again, even working when offline.
By leveraging local storage for fast data retrieval, it also enables our customers to seamlessly work with large and complex datasets made available through our web apps, like Lists with hundreds or thousands of rows. Operations on web app data, like sort and filter, are blazing fast because they occur on the local device. All offline changes synchronize back to the cloud once reconnected to the Internet.
Behind Project Nucleus is Microsoft.SharePoint.exe, a new component delivered alongside OneDrive sync – leveraging the existing OneDrive install and update mechanism. Once installed, it links with the web app by making a smart cache of web app data on the local device. It then acts as a local web server by pulling and pushing data to and from that local cache, instead of the web app always retrieving it from the cloud. This enables offline editing; changes to content occur within the local cache first and then get pushed to the cloud once connection is restored. The result helps save on network bandwidth and eliminate bottlenecks, too.
A visual diagram showing how web apps interact across your local Windows device and cloud services in Microsoft 365.
Microsoft Lists is our first web application that leverages these new capabilities. First, it means you can load the Lists app to view and edit list data whether your online or offline. Second, loading and interacting with lists gets supercharged in all modalities. Finally, views inside synced lists never get throttled – regardless of the number of items in the view or whether those columns are indexed.
New Lists indicators show when your items are being save to your device (offline; as shown above), when the list is synchronizing, and when all is up to date (synced).
Moving forward…
In short, your lists are always on, lightning fast, and less impacted by service-imposed limitations. This is where we start, and we plan to bring these benefits to other web apps over time. Stay tuned – online or offline – for future updates in this space.
Learn more about Progressive Web Apps, including ‘how to’ information for end users. Review all Microsoft Lists new from Microsoft Ignite – including the general availability announcement for Microsoft Lists: Fast and offline [Roadmap ID: 68809]. We have a new end-user ‘how to’ edit lists offline. And admins can review policies to control Lists sync settings.
Take a peek at the technology in action from the related Microsoft Ignite session, “What’s new with Microsoft Lists” (published on November 2nd, 2021 – jump to 13:30 to see the “Fast and offline access to list data” segment):
Thanks for your time to learn more, Andrey Esipov – Principal program manager, Microsoft
by Scott Muniz | Nov 29, 2021 | Security, Technology
This article is contributed. See the original author and article here.
| xen — xen |
guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It would then only be the overflowed (and hence small) number which gets compared against the established upper bound. |
2021-11-24 |
not yet calculated |
CVE-2021-28706
MISC |
afreecatv — afreecatv
|
The vulnerability function is enabled when the streamer service related to the AfreecaTV communicated through web socket using 21201 port. A stack-based buffer overflow leading to remote code execution was discovered in strcpy() operate by “FanTicket” field. It is because of stored data without validation of length. |
2021-11-26 |
not yet calculated |
CVE-2020-7881
MISC |
| aim — aim |
Aim is an open-source, self-hosted machine learning experiment tracking tool. Versions of Aim prior to 3.1.0 are vulnerable to a path traversal attack. By manipulating variables that reference files with “dot-dot-slash (../)� sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. The vulnerability issue is resolved in Aim v3.1.0. |
2021-11-23 |
not yet calculated |
CVE-2021-43775
MISC
CONFIRM
MISC
MISC
MISC |
| alfasado_inc — powercms |
PowerCMS XMLRPC API of PowerCMS 5.19 and earlier, PowerCMS 4.49 and earlier, PowerCMS 3.295 and earlier, and PowerCMS 2 Series (End-of-Life, EOL) allows a remote attacker to execute an arbitrary OS command via unspecified vectors. |
2021-11-24 |
not yet calculated |
CVE-2021-20850
MISC
MISC |
| amazon_web_service — iot_devices |
Connections initialized by the AWS IoT Device SDK v2 for Java (versions prior to 1.4.2), Python (versions prior to 1.6.1), C++ (versions prior to 1.12.7) and Node.js (versions prior to 1.5.3) did not verify server certificate hostname during TLS handshake when overriding Certificate Authorities (CA) in their trust stores on MacOS. This issue has been addressed in aws-c-io submodule versions 0.10.5 onward. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.4.2 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on macOS. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on macOS. Amazon Web Services AWS-C-IO 0.10.4 on macOS. |
2021-11-23 |
not yet calculated |
CVE-2021-40829
MISC
MISC
MISC
MISC
MISC |
| amazon_web_service — iot_devices |
The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on Unix systems. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host’s trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker’s data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user’s private keys to authenticate against the MQTT broker. The ‘aws_tls_ctx_options_override_default_trust_store_*’ function within the aws-c-io submodule has been updated to override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix. |
2021-11-23 |
not yet calculated |
CVE-2021-40830
MISC
MISC
MISC
MISC
MISC |
| amazon_web_service — iot_devices |
The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on macOS systems. Additionally, SNI validation is also not enabled when the CA has been “overridden”. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host’s trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker’s data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user’s private keys to authenticate against the MQTT broker. The ‘aws_tls_ctx_options_override_default_trust_store_*’ function within the aws-c-io submodule has been updated to address this behavior. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.7.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.14.0 on macOS. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.6.0 on macOS. Amazon Web Services AWS-C-IO 0.10.7 on macOS. |
2021-11-23 |
not yet calculated |
CVE-2021-40831
MISC
MISC
MISC
MISC
MISC |
amazon_web_service — iot_devices
|
Connections initialized by the AWS IoT Device SDK v2 for Java (versions prior to 1.3.3), Python (versions prior to 1.5.18), C++ (versions prior to 1.12.7) and Node.js (versions prior to 1.5.1) did not verify server certificate hostname during TLS handshake when overriding Certificate Authorities (CA) in their trust stores on Windows. This issue has been addressed in aws-c-io submodule versions 0.9.13 onward. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.3.3 on Microsoft Windows. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.5.18 on Microsoft Windows. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Microsoft Windows. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Microsoft Windows. |
2021-11-23 |
not yet calculated |
CVE-2021-40828
MISC
MISC
MISC
MISC
MISC |
apache — jspwiki
|
Remote attackers may delete arbitrary files in a system hosting a JSPWiki instance, versions up to 2.11.0.M8, by using a carefuly crafted http request on logout, given that those files are reachable to the user running the JSPWiki instance. Apache JSPWiki users should upgrade to 2.11.0 or later. |
2021-11-24 |
not yet calculated |
CVE-2021-44140
MISC
MISC |
apache — jspwiki
|
A carefully crafted plugin link invocation could trigger an XSS vulnerability on Apache JSPWiki, related to the Denounce plugin, which could allow the attacker to execute javascript in the victim’s browser and get some sensitive information about the victim. Apache JSPWiki users should upgrade to 2.11.0 or later. |
2021-11-24 |
not yet calculated |
CVE-2021-40369
MISC
MISC |
backstage — backstage
|
Backstage is an open platform for building developer portals. In affected versions the auth-backend plugin allows a malicious actor to trick another user into visiting a vulnerable URL that executes an XSS attack. This attack can potentially allow the attacker to exfiltrate access tokens or other secrets from the user’s browser. The default CSP does prevent this attack, but it is expected that some deployments have these policies disabled due to incompatibilities. This is vulnerability is patched in version `0.4.9` of `@backstage/plugin-auth-backend`. |
2021-11-26 |
not yet calculated |
CVE-2021-43776
CONFIRM
MISC |
barcode — barcode
|
Barcode is a GLPI plugin for printing barcodes and QR codes. GLPI instances version 2.x prior to version 2.6.1 with the barcode plugin installed are vulnerable to a path traversal vulnerability. This issue was patched in version 2.6.1. As a workaround, delete the `front/send.php` file. |
2021-11-24 |
not yet calculated |
CVE-2021-43778
CONFIRM
MISC
MISC
MISC |
| basercms — basercms |
BaserCMS is an open source content management system with a focus on Japanese language support. In affected versions users with upload privilege may upload crafted zip files capable of path traversal on the host operating system. This is a vulnerability that needs to be addressed when the management system is used by an unspecified number of users. If you are eligible, please update to the new version as soon as possible. |
2021-11-26 |
not yet calculated |
CVE-2021-41279
CONFIRM
MISC |
basercms — basercms
|
There is a Potential Zip Slip Vulnerability and OS Command Injection Vulnerability on the management system of baserCMS. Users with permissions to upload files may upload crafted zip files which may execute arbitrary commands on the host operating system. This is a vulnerability that needs to be addressed when the management system is used by an unspecified number of users. If you are eligible, please update to the new version as soon as possible. |
2021-11-26 |
not yet calculated |
CVE-2021-41243
CONFIRM
MISC |
bitdefender — endpoint_security_tools
|
A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService component of Bitdefender Endpoint Security Tools allows an attacker to proxy requests to the relay server. This issue affects: Bitdefender Endpoint Security Tools versions prior to 6.6.27.390; versions prior to 7.1.2.33. Bitdefender GravityZone 6.24.1-1. |
2021-11-24 |
not yet calculated |
CVE-2021-3552
MISC |
bitdefender — endpoint_security_tools
|
Improper Access Control vulnerability in the patchesUpdate API as implemented in Bitdefender Endpoint Security Tools for Linux as a relay role allows an attacker to manipulate the remote address used for pulling patches. This issue affects: Bitdefender Endpoint Security Tools for Linux versions prior to 6.6.27.390; versions prior to 7.1.2.33. Bitdefender Unified Endpoint versions prior to 6.2.21.160. Bitdefender GravityZone versions prior to 6.24.1-1. |
2021-11-24 |
not yet calculated |
CVE-2021-3554
MISC |
bitdefender — endpoint_security_tools
|
A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService of Bitdefender Endpoint Security Tools allows an attacker to use the Endpoint Protection relay as a proxy for any remote host. This issue affects: Bitdefender Endpoint Security Tools versions prior to 6.6.27.390; versions prior to 7.1.2.33. Bitdefender Unified Endpoint for Linux versions prior to 6.2.21.160. Bitdefender GravityZone versions prior to 6.24.1-1. |
2021-11-24 |
not yet calculated |
CVE-2021-3553
MISC |
d-link — dwr-932c
|
Missing Authentication for Critical Function vulnerability in debug_post_set.cgi of D-Link DWR-932C E1 firmware allows an unauthenticated attacker to execute administrative actions. |
2021-11-23 |
not yet calculated |
CVE-2021-42783
MISC |
d-link — dwr-932c
|
OS Command Injection vulnerability in debug_fcgi of D-Link DWR-932C E1 firmware allows a remote attacker to perform command injection via a crafted HTTP request. |
2021-11-23 |
not yet calculated |
CVE-2021-42784
MISC |
dell — idrac
|
Dell iDRAC 9 prior to version 4.40.40.00 and iDRAC 8 prior to version 2.80.80.80 contain a Stack Buffer Overflow in Racadm. An authenticated remote attacker may potentially exploit this vulnerability to control process execution and gain access to the underlying operating system. |
2021-11-23 |
not yet calculated |
CVE-2021-36301
CONFIRM |
django — django-wiki
|
In Django-wiki, versions 0.0.20 to 0.7.8 are vulnerable to Stored Cross-Site Scripting (XSS) in Notifications Section. An attacker who has access to edit pages can inject JavaScript payload in the title field. When a victim gets a notification regarding the changes made in the application, the payload in the notification panel renders and loads external JavaScript. |
2021-11-23 |
not yet calculated |
CVE-2021-25986
CONFIRM
MISC |
f-secure — f-secure
|
A vulnerability affecting F-Secure antivirus engine was discovered whereby unpacking UPX file can lead to denial-of-service. The vulnerability can be exploited remotely by an attacker. A successful attack will result in denial-of-service of the antivirus engine. |
2021-11-26 |
not yet calculated |
CVE-2021-40833
MISC
MISC |
gin-vue-admin — gin-vue-admin
|
Gin-Vue-Admin before 2.4.6 mishandles a SQL database. |
2021-11-24 |
not yet calculated |
CVE-2021-44219
MISC
MISC |
hejhome — gwk-ic052
|
HejHome GKW-IC052 IP Camera contained a hard-coded credentials vulnerability. This issue allows remote attackers to operate the IP Camera.(reboot, factory reset, snapshot etc..) |
2021-11-26 |
not yet calculated |
CVE-2021-26611
MISC |
hitachi — multiple_devices
|
Improper Input Validation vulnerability in the APDU parser in the Bidirectional Communication Interface (BCI) IEC 60870-5-104 function of Hitachi Energy RTU500 series allows an attacker to cause the receiving RTU500 CMU of which the BCI is enabled to reboot when receiving a specially crafted message. By default, BCI IEC 60870-5-104 function is disabled (not configured). This issue affects: Hitachi Energy RTU500 series CMU Firmware version 12.0.* (all versions); CMU Firmware version 12.2.* (all versions); CMU Firmware version 12.4.* (all versions). |
2021-11-26 |
not yet calculated |
CVE-2021-35533
CONFIRM |
huawei — multiple_products
|
There is a weak secure algorithm vulnerability in Huawei products. A weak secure algorithm is used in a module. Attackers can exploit this vulnerability by capturing and analyzing the messages between devices to obtain information. This can lead to information leak.Affected product versions include: IPS Module V500R005C00SPC100, V500R005C00SPC200; NGFW Module V500R005C00SPC100, V500R005C00SPC200; Secospace USG6300 V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, V500R005C00SPC100, V500R005C00SPC200; Secospace USG6500 V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, V500R005C00SPC100, V500R005C00SPC200; Secospace USG6600 V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, V500R005C00SPC100, V500R005C00SPC200; USG9500 V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, V500R005C00SPC100, V500R005C00SPC200. |
2021-11-23 |
not yet calculated |
CVE-2021-22356
MISC |
| huawei — smartphones |
There is an Improper permission vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may affect service availability. |
2021-11-23 |
not yet calculated |
CVE-2021-37030
MISC |
| huawei — smartphones |
There is an Identity verification vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may affect service availability. |
2021-11-23 |
not yet calculated |
CVE-2021-37029
MISC |
| huawei — smartphones |
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37026
MISC |
| huawei — smartphones |
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37025
MISC |
| huawei — smartphones |
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37024
MISC |
| huawei — smartphones |
There is a Data Processing Errors vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37018
MISC |
| huawei — smartphones |
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the availability of users is affected. |
2021-11-23 |
not yet calculated |
CVE-2021-37013
MISC |
| huawei — smartphones |
There is a Out-of-bounds Read vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37007
MISC |
| huawei — smartphones |
There is a Remote DoS vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the app to exit unexpectedly. |
2021-11-23 |
not yet calculated |
CVE-2021-37031
MISC |
| huawei — smartphones |
There is a Bypass vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may cause Digital Balance to fail to work. |
2021-11-23 |
not yet calculated |
CVE-2021-37032
MISC |
| huawei — smartphones |
The affected controllers do not properly sanitize the input containing code syntax. As a result, an attacker could craft code to alter the intended controller flow of the software. |
2021-11-22 |
not yet calculated |
CVE-2021-38448
CONFIRM |
| huawei — smartphones |
There is an Injection attack vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may affect service availability. |
2021-11-23 |
not yet calculated |
CVE-2021-37033
MISC |
| huawei — smartphones |
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37017
MISC |
huawei — smartphones
|
There is a Remote DoS vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the app to exit unexpectedly. |
2021-11-23 |
not yet calculated |
CVE-2021-37035
MISC |
huawei — smartphones
|
There is a Data Processing Errors vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37012
MISC |
huawei — smartphones
|
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37019
MISC |
huawei — smartphones
|
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37003
MISC |
huawei — smartphones
|
There is a Out-of-bounds Read vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause Information Disclosure or Denial of Service. |
2021-11-23 |
not yet calculated |
CVE-2021-37016
MISC |
huawei — smartphones
|
There is a Out-of-bounds Read vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37015
MISC |
huawei — smartphones
|
There is an Unstandardized field names in Huawei Smartphone.Successful exploitation of this vulnerability may affect service confidentiality. |
2021-11-23 |
not yet calculated |
CVE-2021-37034
MISC |
huawei — smartphones
|
There is a Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the confidentiality of users is affected. |
2021-11-23 |
not yet calculated |
CVE-2021-37010
MISC |
huawei — smartphones
|
There is a Improper Access Control vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause media files which can be reads and writes in non-distributed directories on any device on the network.. |
2021-11-23 |
not yet calculated |
CVE-2021-37023
MISC |
huawei — smartphones
|
There is a Configuration vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the confidentiality of users is affected. |
2021-11-23 |
not yet calculated |
CVE-2021-37009
MISC |
huawei — smartphones
|
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37008
MISC |
huawei — smartphones
|
There is a Improper Preservation of Permissions vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the confidentiality of users is affected. |
2021-11-23 |
not yet calculated |
CVE-2021-37006
MISC |
huawei — smartphones
|
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37005
MISC |
huawei — smartphones
|
There is a Improper Input Validation vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause kernel crash. |
2021-11-23 |
not yet calculated |
CVE-2021-37004
MISC |
huawei — smartphones
|
There is a Heap-based Buffer Overflow vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause root permission which can be escalated. |
2021-11-23 |
not yet calculated |
CVE-2021-37022
MISC |
ibm — sterling_connect
|
IBM Sterling Connect:Direct Web Services 1.0 and 6.0 uses an inadequate account lockout setting that could allow a remote attacker to brute force account credentials. IBM X-Force ID: 209507. |
2021-11-23 |
not yet calculated |
CVE-2021-38890
CONFIRM
XF |
ibm — sterling_connect
|
IBM Sterling Connect:Direct Web Services 1.0 and 6.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 209508. |
2021-11-23 |
not yet calculated |
CVE-2021-38891
CONFIRM
XF |
janus-gateway — janus-gateway
|
janus-gateway is vulnerable to Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) |
2021-11-27 |
not yet calculated |
CVE-2021-4020
CONFIRM
MISC |
joeattardi — emoji-button
|
@joeattardi/emoji-button is a Vanilla JavaScript emoji picker component. In affected versions there are two vectors for XSS attacks: a URL for a custom emoji, and an i18n string. In both of these cases, a value can be crafted such that it can insert a `script` tag into the page and execute malicious code. |
2021-11-26 |
not yet calculated |
CVE-2021-43785
CONFIRM
MISC
MISC |
kaspersky — password_manager
|
A component in Kaspersky Password Manager could allow an attacker to elevate a process Integrity level from Medium to High. |
2021-11-23 |
not yet calculated |
CVE-2021-35052
MISC |
keepalived — keepalived
|
In Keepalived through 2.2.4, the D-Bus policy does not sufficiently restrict the message destination, allowing any user to inspect and manipulate any property. This leads to access-control bypass in some situations in which an unrelated D-Bus system service has a settable (writable) property |
2021-11-26 |
not yet calculated |
CVE-2021-44225
MISC
MISC |
mcafee — policy_auditor
|
A Reflected Cross-Site Scripting vulnerability in McAfee Policy Auditor prior to 6.5.2 allows a remote unauthenticated attacker to inject arbitrary web script or HTML via the profileNodeID request parameters. The malicious script is reflected unmodified into the Policy Auditor web-based interface which could lead to the extraction of end user session token or login credentials. These may be used to access additional security-critical applications or conduct arbitrary cross-domain requests. |
2021-11-23 |
not yet calculated |
CVE-2021-31851
CONFIRM |
mcafee — policy_auditor
|
A Reflected Cross-Site Scripting vulnerability in McAfee Policy Auditor prior to 6.5.2 allows a remote unauthenticated attacker to inject arbitrary web script or HTML via the UID request parameter. The malicious script is reflected unmodified into the Policy Auditor web-based interface which could lead to the extract of end user session token or login credentials. These may be used to access additional security-critical applications or conduct arbitrary cross-domain requests. |
2021-11-23 |
not yet calculated |
CVE-2021-31852
CONFIRM |
microsoft — azure
|
Azure Active Directory Information Disclosure Vulnerability |
2021-11-24 |
not yet calculated |
CVE-2021-42306
N/A |
microsoft — edge
|
Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability |
2021-11-24 |
not yet calculated |
CVE-2021-43221
N/A |
microsoft — edge
|
Microsoft Edge (Chromium-based) Spoofing Vulnerability |
2021-11-24 |
not yet calculated |
CVE-2021-42308
N/A |
microsoft — edge
|
Microsoft Edge for iOS Spoofing Vulnerability |
2021-11-24 |
not yet calculated |
CVE-2021-43220
N/A |
microsoft — windows
|
Windows 10 Update Assistant Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-42297. |
2021-11-24 |
not yet calculated |
CVE-2021-43211
N/A |
microsoft — windows
|
Windows 10 Update Assistant Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-43211. |
2021-11-24 |
not yet calculated |
CVE-2021-42297
N/A
MISC |
mitsubishi_electric — mercari_app
|
Improper authorization in handler for custom URL scheme vulnerability in Android App ‘Mercari (Merpay) – Marketplace and Mobile Payments App’ (Japan version) versions prior to 4.49.1 allows a remote attacker to lead a user to access an arbitrary website and the website launches an arbitrary Activity of the app via the vulnerable App, which may result in Mercari account’s access token being obtained. |
2021-11-24 |
not yet calculated |
CVE-2021-20835
MISC |
mitsubishi_electric — multiple_got2000_series
|
Improper input validation vulnerability in GOT2000 series GT27 model all versions, GOT2000 series GT25 model all versions, GOT2000 series GT23 model all versions, GOT2000 series GT21 model all versions, GOT SIMPLE series GS21 model all versions, and GT SoftGOT2000 all versions allows an remote unauthenticated attacker to write a value that exceeds the configured input range limit by sending a malicious packet to rewrite the device value. As a result, the system operation may be affected, such as malfunction. |
2021-11-23 |
not yet calculated |
CVE-2021-20601
MISC
MISC
MISC |
| mongodb — mongodb |
An authorized user may trigger an invariant which may result in denial of service or server exit if a relevant aggregation request is sent to a shard. Usually, the requests are sent via mongos and special privileges are required in order to know the address of the shards and to log in to the shards of an auth enabled environment. |
2021-11-24 |
not yet calculated |
CVE-2021-32037
MISC |
octopus — tentacle
|
When Octopus Tentacle is installed on a Linux operating system, the systemd service file permissions are misconfigured. This could lead to a local unprivileged user modifying the contents of the systemd service file to gain privileged access. |
2021-11-24 |
not yet calculated |
CVE-2021-31822
MISC |
qnap — viostor
|
A command injection vulnerability has been reported to affect QNAP device, VioStor. If exploited, this vulnerability allows remote attackers to run arbitrary commands. We have already fixed this vulnerability in the following versions of QVR: QVR FW 5.1.6 build 20211109 and later |
2021-11-26 |
not yet calculated |
CVE-2021-38685
CONFIRM |
qnap — viostor
|
An improper authentication vulnerability has been reported to affect QNAP device, VioStor. If exploited, this vulnerability allows attackers to compromise the security of the system. We have already fixed this vulnerability in the following versions of QVR: QVR FW 5.1.6 build 20211109 and later |
2021-11-26 |
not yet calculated |
CVE-2021-38686
CONFIRM |
redash — redash
|
Redash is a package for data visualization and sharing. If an admin sets up Redash versions 10.0.0 and prior without explicitly specifying the `REDASH_COOKIE_SECRET` or `REDASH_SECRET_KEY` environment variables, a default value is used for both that is the same across all installations. In such cases, the instance is vulnerable to attackers being able to forge sessions using the known default value. This issue only affects installations where the `REDASH_COOKIE_SECRET or REDASH_SECRET_KEY` environment variables have not been explicitly set. This issue does not affect users of the official Redash cloud images, Redash’s Digital Ocean marketplace droplets, or the scripts in the `getredash/setup` repository. These instances automatically generate unique secret keys during installation. One can verify whether one’s instance is affected by checking the value of the `REDASH_COOKIE_SECRET` environment variable. If it is `c292a0a3aa32397cdb050e233733900f`, should follow the steps to secure the instance, outlined in the GitHub Security Advisory. |
2021-11-24 |
not yet calculated |
CVE-2021-41192
CONFIRM
MISC |
redash — redash
|
Redash is a package for data visualization and sharing. In Redash version 10.0 and prior, the implementation of Google Login (via OAuth) incorrectly uses the `state` parameter to pass the next URL to redirect the user to after login. The `state` parameter should be used for a Cross-Site Request Forgery (CSRF) token, not a static and easily predicted value. This vulnerability does not affect users who do not use Google Login for their instance of Redash. A patch in the `master` and `release/10.x.x` branches addresses this by replacing `Flask-Oauthlib` with `Authlib` which automatically provides and validates a CSRF token for the state variable. The new implementation stores the next URL on the user session object. As a workaround, one may disable Google Login to mitigate the vulnerability. |
2021-11-24 |
not yet calculated |
CVE-2021-43777
CONFIRM
MISC |
redash — redash
|
Redash is a package for data visualization and sharing. In versions 10.0 and priorm the implementation of URL-loading data sources like JSON, CSV, or Excel is vulnerable to advanced methods of Server Side Request Forgery (SSRF). These vulnerabilities are only exploitable on installations where a URL-loading data source is enabled. As of time of publication, the `master` and `release/10.x.x` branches address this by applying the Advocate library for making http requests instead of the requests library directly. Users should upgrade to version 10.0.1 to receive this patch. There are a few workarounds for mitigating the vulnerability without upgrading. One can disable the vulnerable data sources entirely, by adding the following env variable to one’s configuration, making them unavailable inside the webapp. One can switch any data source of certain types (viewable in the GitHub Security Advisory) to be `View Only` for all groups on the Settings > Groups > Data Sources screen. For users unable to update an admin may modify Redash’s configuration through environment variables to mitigate this issue. Depending on the version of Redash, an admin may also need to run a CLI command to re-encrypt some fields in the database. The `master` and `release/10.x.x` branches as of time of publication have removed the default value for `REDASH_COOKIE_SECRET`. All future releases will also require this to be set explicitly. For existing installations, one will need to ensure that explicit values are set for the `REDASH_COOKIE_SECRET` and `REDASH_SECRET_KEY `variables. |
2021-11-24 |
not yet calculated |
CVE-2021-43780
CONFIRM
MISC |
sophos — hitmanpro_alert
|
A local administrator could prevent the HMPA service from starting despite tamper protection using an unquoted service path vulnerability in the HMPA component of Sophos Intercept X Advanced and Sophos Intercept X Advanced for Server before version 2.0.23, as well as Sophos Exploit Prevention before version 3.8.3. |
2021-11-26 |
not yet calculated |
CVE-2021-25269
CONFIRM |
sophos — sophos
|
An authenticated user could potentially execute code via an SQLi vulnerability in the user portal of SG UTM before version 9.708 MR8. |
2021-11-26 |
not yet calculated |
CVE-2021-36807
CONFIRM |
symfony — symfony
|
Symfony/SecurityBundle is the security system for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Since the rework of the Remember me cookie in version 5.3.0, the cookie is not invalidated when the user changes their password. Attackers can therefore maintain their access to the account even if the password is changed as long as they have had the chance to login once and get a valid remember me cookie. Starting with version 5.3.12, Symfony makes the password part of the signature by default. In that way, when the password changes, then the cookie is not valid anymore. |
2021-11-24 |
not yet calculated |
CVE-2021-41268
CONFIRM
MISC
MISC
MISC |
symfony — symfony
|
Symfony/Http-Kernel is the HTTP kernel component for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Headers that are not part of the “trusted_headers” allowed list are ignored and protect users from “Cache poisoning” attacks. In Symfony 5.2, maintainers added support for the `X-Forwarded-Prefix` headers, but this header was accessible in SubRequest, even if it was not part of the “trusted_headers” allowed list. An attacker could leverage this opportunity to forge requests containing a `X-Forwarded-Prefix` header, leading to a web cache poisoning issue. Versions 5.3.12 and later have a patch to ensure that the `X-Forwarded-Prefix` header is not forwarded to subrequests when it is not trusted. |
2021-11-24 |
not yet calculated |
CVE-2021-41267
CONFIRM
MISC
MISC
MISC |
symfony — symfony
|
Symfony/Serializer handles serializing and deserializing data structures for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Symfony versions 4.1.0 before 4.4.35 and versions 5.0.0 before 5.3.12 are vulnerable to CSV injection, also known as formula injection. In Symfony 4.1, maintainers added the opt-in `csv_escape_formulas` option in the `CsvEncoder`, to prefix all cells starting with `=`, `+`, `-` or `@` with a tab `t`. Since then, OWASP added 2 chars in that list: Tab (0x09) and Carriage return (0x0D). This makes the previous prefix char (Tab `t`) part of the vulnerable characters, and OWASP suggests using the single quote `’` for prefixing the value. Starting with versions 4.4.34 and 5.3.12, Symfony now follows the OWASP recommendations and uses the single quote `’` to prefix formulas and add the prefix to cells starting by `t`, `r` as well as `=`, `+`, `-` and `@`. |
2021-11-24 |
not yet calculated |
CVE-2021-41270
MISC
CONFIRM
MISC
MISC |
synapse — synapse
|
Synapse is a package for Matrix homeservers written in Python 3/Twisted. Prior to version 1.47.1, Synapse instances with the media repository enabled can be tricked into downloading a file from a remote server into an arbitrary directory. No authentication is required for the affected endpoint. The last 2 directories and file name of the path are chosen randomly by Synapse and cannot be controlled by an attacker, which limits the impact. Homeservers with the media repository disabled are unaffected. Homeservers with a federation whitelist are also unaffected, since Synapse will check the remote hostname, including the trailing `../`s, against the whitelist. Server administrators should upgrade to 1.47.1 or later. Server administrators using a reverse proxy could, at the expense of losing media functionality, may block the certain endpoints as a workaround. Alternatively, non-containerized deployments can be adapted to use the hardened systemd config. |
2021-11-23 |
not yet calculated |
CVE-2021-41281
MISC
CONFIRM
MISC |
| synk — synk |
This affects all versions of package docker-cli-js. If the command parameter of the Docker.command method can at least be partially controlled by a user, they will be in a position to execute any arbitrary OS commands on the host system. |
2021-11-22 |
not yet calculated |
CVE-2021-23732
CONFIRM |
synk — synk
|
This affects all versions of package html-to-csv. When there is a formula embedded in a HTML page, it gets accepted without any validation and the same would be pushed while converting it into a CSV file. Through this a malicious actor can embed or generate a malicious link or execute commands via CSV files. |
2021-11-26 |
not yet calculated |
CVE-2021-23654
CONFIRM
CONFIRM |
tightvnc — viewer
|
Buffer Overflow vulnerability in tvnviewer.exe of TightVNC Viewer allows a remote attacker to execute arbitrary instructions via a crafted FramebufferUpdate packet from a VNC server. |
2021-11-23 |
not yet calculated |
CVE-2021-42785
MISC |
ubuntu — ark_library
|
ARK library allows attackers to execute remote code via the parameter(path value) of Ark_NormalizeAndDupPAthNameW function because of an integer overflow. |
2021-11-26 |
not yet calculated |
CVE-2021-26615
MISC |
unifi — protect
|
A Cross-Origin Resource Sharing (CORS) vulnerability found in UniFi Protect application Version 1.19.2 and earlier allows a malicious actor who has convinced a privileged user to access a URL with malicious code to take over said user’s account.This vulnerability is fixed in UniFi Protect application Version 1.20.0 and later. |
2021-11-24 |
not yet calculated |
CVE-2021-22957
MISC |
vmware — vsphere_web_client
|
The vSphere Web Client (FLEX/Flash) contains an unauthorized arbitrary file read vulnerability. A malicious actor with network access to port 443 on vCenter Server may exploit this issue to gain access to sensitive information. |
2021-11-24 |
not yet calculated |
CVE-2021-21980
MISC |
vmware — vsphere_web_client
|
The vSphere Web Client (FLEX/Flash) contains an SSRF (Server Side Request Forgery) vulnerability in the vSAN Web Client (vSAN UI) plug-in. A malicious actor with network access to port 443 on vCenter Server may exploit this issue by accessing a URL request outside of vCenter Server or accessing an internal service. |
2021-11-24 |
not yet calculated |
CVE-2021-22049
MISC |
| wordpress — wordpress |
The ImageBoss WordPress plugin before 3.0.6 does not sanitise and escape its Source Name setting, which could allow high privilege users to perform Cross-Site Scripting attacks |
2021-11-23 |
not yet calculated |
CVE-2021-24888
MISC |
wordpress — wordpress
|
WordPress before 5.8 lacks support for the Update URI plugin header. This makes it easier for remote attackers to execute arbitrary code via a supply-chain attack against WordPress installations that use any plugin for which the slug satisfies the naming constraints of the WordPress.org Plugin Directory but is not yet present in that directory. |
2021-11-25 |
not yet calculated |
CVE-2021-44223
MISC
MISC |
wordpress — wordpress
|
The Elementor Website Builder WordPress plugin before 3.1.4 does not sanitise or escape user input appended to the DOM via a malicious hash, resulting in a DOM Cross-Site Scripting issue |
2021-11-23 |
not yet calculated |
CVE-2021-24891
MISC
MISC |
wordpress — wordpress
|
Insecure Direct Object Reference in edit function of Advanced Forms (Free & Pro) before 1.6.9 allows authenticated remote attacker to change arbitrary user’s email address and request for reset password, which could lead to take over of WordPress’s administrator account. To exploit this vulnerability, an attacker must register to obtain a valid WordPress’s user and use such user to authenticate with WordPress in order to exploit the vulnerable edit function. |
2021-11-23 |
not yet calculated |
CVE-2021-24892
MISC
MISC |
wordpress — wordpress
|
The Reviews Plus WordPress plugin before 1.2.14 does not validate the submitted rating, allowing submission of long integer, causing a Denial of Service in the review section when an authenticated user submit such rating and the reviews are set to be displayed on the post/page |
2021-11-23 |
not yet calculated |
CVE-2021-24894
CONFIRM
MISC |
| xen — xen |
issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error handling in certain PoD cases has been insufficient in that in particular partial success of some operations was not properly accounted for. There are two code paths affected – page removal (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix to both issues.) |
2021-11-24 |
not yet calculated |
CVE-2021-28705
MISC |
xen — xen
|
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEM_decrease_reservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2). |
2021-11-24 |
not yet calculated |
CVE-2021-28704
MISC |
xen — xen
|
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEM_decrease_reservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2). |
2021-11-24 |
not yet calculated |
CVE-2021-28707
MISC |
xen — xen
|
PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEM_decrease_reservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2). |
2021-11-24 |
not yet calculated |
CVE-2021-28708
MISC |
xen — xen
|
issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error handling in certain PoD cases has been insufficient in that in particular partial success of some operations was not properly accounted for. There are two code paths affected – page removal (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix to both issues.) |
2021-11-24 |
not yet calculated |
CVE-2021-28709
MISC |
yamaha — multiple_routers
|
Improper neutralization of HTTP request headers for scripting syntax vulnerability in the Web GUI of RTX830 Rev.15.02.17 and earlier, NVR510 Rev.15.01.18 and earlier, NVR700W Rev.15.00.19 and earlier, and RTX1210 Rev.14.01.38 and earlier allows a remote authenticated attacker to obtain sensitive information via a specially crafted web page. |
2021-11-24 |
not yet calculated |
CVE-2021-20844
MISC
MISC
MISC
MISC |
yamaha — multiple_routers
|
Cross-site script inclusion vulnerability in the Web GUI of RTX830 Rev.15.02.17 and earlier, NVR510 Rev.15.01.18 and earlier, NVR700W Rev.15.00.19 and earlier, and RTX1210 Rev.14.01.38 and earlier allows a remote authenticated attacker to alter the settings of the product via a specially crafted web page. |
2021-11-24 |
not yet calculated |
CVE-2021-20843
MISC
MISC
MISC
MISC |
zoom — client_for_meetings
|
A buffer overflow vulnerability was discovered in Zoom Client for Meetings (for Android, iOS, Linux, macOS, and Windows) before version 5.8.4, Zoom Client for Meetings for Blackberry (for Android and iOS) before version 5.8.1, Zoom Client for Meetings for intune (for Android and iOS) before version 5.8.4, Zoom Client for Meetings for Chrome OS before version 5.0.1, Zoom Rooms for Conference Room (for Android, AndroidBali, macOS, and Windows) before version 5.8.3, Controllers for Zoom Rooms (for Android, iOS, and Windows) before version 5.8.3, Zoom VDI before version 5.8.4, Zoom Meeting SDK for Android before version 5.7.6.1922, Zoom Meeting SDK for iOS before version 5.7.6.1082, Zoom Meeting SDK for macOS before version 5.7.6.1340, Zoom Meeting SDK for Windows before version 5.7.6.1081, Zoom Video SDK (for Android, iOS, macOS, and Windows) before version 1.1.2, Zoom On-Premise Meeting Connector Controller before version 4.8.12.20211115, Zoom On-Premise Meeting Connector MMR before version 4.8.12.20211115, Zoom On-Premise Recording Connector before version 5.1.0.65.20211116, Zoom On-Premise Virtual Room Connector before version 4.4.7266.20211117, Zoom On-Premise Virtual Room Connector Load Balancer before version 2.5.5692.20211117, Zoom Hybrid Zproxy before version 1.0.1058.20211116, and Zoom Hybrid MMR before version 4.6.20211116.131_x86-64. This can potentially allow a malicious actor to crash the service or application, or leverage this vulnerability to execute arbitrary code. |
2021-11-24 |
not yet calculated |
CVE-2021-34423
MISC |
zoom — client_for_meetings
|
A vulnerability was discovered in the Zoom Client for Meetings (for Android, iOS, Linux, macOS, and Windows) before version 5.8.4, Zoom Client for Meetings for Blackberry (for Android and iOS) before version 5.8.1, Zoom Client for Meetings for intune (for Android and iOS) before version 5.8.4, Zoom Client for Meetings for Chrome OS before version 5.0.1, Zoom Rooms for Conference Room (for Android, AndroidBali, macOS, and Windows) before version 5.8.3, Controllers for Zoom Rooms (for Android, iOS, and Windows) before version 5.8.3, Zoom VDI before version 5.8.4, Zoom Meeting SDK for Android before version 5.7.6.1922, Zoom Meeting SDK for iOS before version 5.7.6.1082, Zoom Meeting SDK for macOS before version 5.7.6.1340, Zoom Meeting SDK for Windows before version 5.7.6.1081, Zoom Video SDK (for Android, iOS, macOS, and Windows) before version 1.1.2, Zoom on-premise Meeting Connector before version 4.8.12.20211115, Zoom on-premise Meeting Connector MMR before version 4.8.12.20211115, Zoom on-premise Recording Connector before version 5.1.0.65.20211116, Zoom on-premise Virtual Room Connector before version 4.4.7266.20211117, Zoom on-premise Virtual Room Connector Load Balancer before version 2.5.5692.20211117, Zoom Hybrid Zproxy before version 1.0.1058.20211116, and Zoom Hybrid MMR before version 4.6.20211116.131_x86-64 which potentially allowed for the exposure of the state of process memory. This issue could be used to potentially gain insight into arbitrary areas of the product’s memory. |
2021-11-24 |
not yet calculated |
CVE-2021-34424
MISC |
zyxel — multiple_firmware
|
A vulnerability in specific versions of Zyxel NBG6818, NBG7815, WSQ20, WSQ50, WSQ60, and WSR30 firmware with pre-configured password management could allow an attacker to obtain root access of the device, if the local attacker dismantles the device and uses a USB-to-UART cable to connect the device, or if the remote assistance feature had been enabled by an authenticated user. |
2021-11-23 |
not yet calculated |
CVE-2021-35033
CONFIRM |
Recent Comments