Posts Tagged

Framework

In brief: Microsoft’s Fluid Framework documents explained

With users now able to get their hands on Microsoft’s latest document format – rolled out under the umbrella of the Fluid Framework – the company is hoping it can deliver on its promises of better productivity and collaboration online.

The Fluid Framework was announced at Microsoft’s Build developer conference in 2019, and at Build 2020 – a virtual-only event this year – the company made the format available for user preview for Microsoft 365 Enterprise and education subscribers enrolled in Targeted Release. It’s also available as open source software; Microsoft said the code and SDK will be available on GitHub soon.

The goal behind Fluid is an ambitious one: users can create discreet pieces of content – such as text, tables, graphs or lists – that live on the web instead of the desktop or a SharePoint drive and are blower agnostic. These artifacts can then be collaborated on or snapped together with other elements in near-to-real-time across a variety of environments.

Nick McQuire, vice president for enterprise research at CCS Insight, believes Microsoft is on its way to making Office “a development environment,” where organizations can start to “embed [Fluid] in business processes and deeper collaboration environments across your company.

“Microsoft does feel a bit of pressure to break down the silos within various, different applications out there, as well,” he said. “Whether it is Google or other flavors of collaboration software, there are others that are pushing the boundaries of what it is to collaborate.”

How it works

The basic Fluid experience involves a clean user experience reminiscent of Google Docs or Dropbox Paper. It is essentially a blank slate, with the option to create a document or Fluid artifact that can then be shared with your network.

Underpinned by JavaScript APIs, these elements can be dropped in to an email via Outlook or other productivity apps via Office.com for starters. (Teams compatibility is slated for later this year.) And by open-sourcing the framework, Microsoft is allowing developers to work Fluid elements into a variety of other locations in the future, essentially allowing these items free roam on the internet and in various productivity apps already in use.

“Discovering the full potential of the Fluid Framework can only be accomplished through creating a diverse, open, and vibrant developer community,” Jared Spataro, corporate vice president for Microsoft 365, said in an announcement this week.

Where Fluid differs from the likes of Google Docs is how it enables people to work together on an item – wherever it resides. Instead of opening a proposed agenda from an email and editing it in Word, a users can just edit it in place in the email, with all changes staying up to date. In practice, it looks like a typical Google Docs experience, with colleagues’ avatars appearing next to the line on which they’re working in real time.

If that sounds potentially chaotic, that’s because it is. Microsoft is looking to achieve true real-time collaboration, where changes are relayed immediately and multiple users can work on items simultaneously, even if they aren’t “in” the same document. That could lead to conflicts with co-workers, and concerns about version control.

Use cases will be fluid (sorry), but early examples include: tracking action items, building a crowd-sourced meeting agenda with minutes or sharing the results of a recent project with a team in a virtual meeting.

“It is becoming clear you cannot single handedly live in one application, so the ability for companies to make that workflow more adaptive and easier for people to do tasks across different applications, while retaining an experience that they prefer to work in, is becoming really important,” McQuire said.

What next?

Further in the future, Microsoft envisions a model where software bots – like its Cortana virtual assistant – can work alongside users to translate text, suggest edits and perform checks directly within Fluid components.

McQuire believes the success of Fluid depends on the developer community. “They have to be the starting point to take Fluid in a direction that will bring some innovation into Office and 365 overall,” he said.

Copyright © 2020 IDG Communications, Inc.



Source link

That malware with its own backdoor into Android’s framework? Don’t worry Google’s on it. (Gulp!)

Google last week (June 6) confirmed that cyberthieves had managed to pre-install malware into the Android framework backdoor. In short, the malware appeared to be blessed by Google at the deepest point within Android.

“In the Google Play app context, installation meant that [the malware] didn’t have to turn on installation from unknown sources and all app installs looked like they were from Google Play,” wrote Lukasz Siewierski, of the Android security and privacy team, in a blog post. “The apps were downloaded from the C&C server and the communication with the C&C was encrypted using the same custom encryption routine using double XOR and zip. The downloaded and installed apps used the package names of unpopular apps available on Google Play. They didn’t have any relation to the apps on Google Play apart from the same package name.”

Enterprise CISOs and CSOs, along with CIOs, are discovering that trusting the major mobile operating system companies today — Apple and Google — to handle their end of security protections is foolhardy. Due to the nature of the Apple ecosystem (a total of one handset maker, which allows for a much more closed system), iOS is slightly more secure, but only slightly.

Still, Google’s new admission certainly makes Apple look a little better in the security area. The issue isn’t with the operating systems per se — both iOS and Android have reasonably secure code. It’s with apps offered to enterprises and consumers through the officially sanctioned app depositories. Enterprise security pros already know that neither Apple nor Google does a heck of a lot to validate the security of the apps. At best, both are checking for policy and copyright issues far more than the presence of malware.

But that’s dealing with true third-party apps. Apps coming directly from Apple and Google can be trusted — or so was thought until Google’s disclosure.

The incident that Google admitted happened some two years ago, and the blog post didn’t say why Google didn’t announce it at the time, or why it chose to now. It might be that Google wanted to make sure it had sufficiently closed this hole before announcing it, but two years is an awfully long time to know about this serious a hole and be silent about it.

So what actually happened? Google gets points for publishing lots of details. The background to Google’s story begins a year earlier than this — so, three years ago —  with a series of spam ad-displaying apps called Triada.

“The main purpose of Triada apps was to install spam apps on a device that displays ads,” Siewierski wrote. “The creators of Triada collected revenue from the ads displayed by the spam apps. The methods Triada used were complex and unusual for these types of apps. Triada apps started as rooting trojans, but as Google Play Protect strengthened defenses against rooting exploits, Triada apps were forced to adapt, progressing to a system image backdoor.”

Siewierski then detailed the app’s methodology: “Triada’s first action was to install a type of superuser (su) binary file. This su binary allowed other apps on the device to use root permissions. The su binary used by Triada required a password, so was unique compared to regular su binary files common with other Linux systems. The binary accepted two passwords: od2gf04pd9 and ac32dorbdq. Depending on which one was provided, the binary either ran the command given as an argument as root or concatenated all of the arguments, ran that concatenation preceded by sh, then ran them as root. Either way, the app had to know the correct password to run the command as root.”

The app used an impressively sophisticated system to free up the space it needed, but avoiding — to the extent it could — deleting anything that would alert IT or the consumer to a problem. “Weight watching included several steps and attempted to free up space on the device’s user partition and system partition. Using a blacklist and whitelist of apps, it first removed all the apps on its blacklist. If more free space was required, it would remove all other apps leaving only the apps on the whitelist. This process freed space while ensuring the apps needed for the phone to function properly were not removed.” He also noted that “in addition to installing apps that display ads, Triada injected code into four web browsers: AOSP (com.android.browser), 360 Secure (com.qihoo.browser), Cheetah (com.ijinshan.browser_fast) and Oupeng (com.oupeng.browser).”

At that point, Siewierski wrote, Google detected the malware efforts and was able to remove Triada samples using Google Play Protect and tried to thwart Triada in other ways. That’s when Triada fought back, around the summer of 2017. “Instead of rooting the device to obtain elevating privileges, Triada evolved to become a pre-installed Android framework backdoor. The changes to Triada included an additional call in the Android framework log function. By backdooring the log function, the additional code executes every time the log method is called. That is, every time any app on the phone tries to log something. These log attempts happen many times per second, so the additional code [was] running non-stop. The additional code also executes in the context of the app logging a message, so Triada can execute code in any app context. The code injection framework in early versions of Triada worked on Android releases prior to Marshmallow. The main purpose of the backdoor function was to execute code in another app’s context. The backdoor attempts to execute additional code every time the app needs to log something.”

The malware then got creative about finding ways to avoid — or to at least delay — detection.

“Each MMD file had a specific file name of the format <MD5 of the process name>36.jmd. By using the MD5 of the process name, the Triada authors tried to obscure the injection target. However, the pool of all available process names is fairly small, so this hash was easily reversible. We identified two code injection targets: com.android.systemui (the System UI app) and com.android.vending (the Google Play app). The first target was injected to get the GET_REAL_TASKS permission. This is a signature-level permission, which means that it can’t be held by ordinary Android apps. Starting with Android Lollipop, the getRecentTasks() method is deprecated to protect users’ privacy. However, apps holding the GET_REAL_TASKS permission can get the result of this method call. To hold the GET_REAL_TASKS permission, an app has to be signed with a specific certificate, the device’s platform cert, which is held by the OEM. Triada didn’t have access to this cert. Instead it executed additional code in the System UI app, which has the GET_REAL_TASKS permission.”

The malware had one more trick up its evil sleeve. “The last piece of the puzzle was the way the backdoor in the log function communicated with the installed apps. This communication prompted the investigation: the change in Triada made it appear that there was another component on the system image. The apps could communicate with the Triada backdoor by logging a line with a specific predefined tag and message. The reverse communication was more complicated. The backdoor used Java properties to relay a message to the app. These properties were key-value pairs similar to Android system properties, but they were scoped to a specific process. Setting one of these properties in one app context ensures that other apps won’t see this property. Despite that, some versions of Triada indiscriminately created the properties in every single app process.”

At the end of the post — which has a lot more code included and is worth a thorough read — Google offers some thoughts on next steps. Look carefully at its suggestions and see if you can detect who seems to emerge blameless from all of this? From Google’s suggestions: “OEMs should ensure that all third-party code is reviewed and can be tracked to its source. Additionally, any functionality added to the system image should only support requested features. It’s a good practice to perform a security review of a system image after adding third-party code. Triada was inconspicuously included in the system image as third-party code for additional features requested by the OEMs. This highlights the need for thorough ongoing security reviews of system images before the device is sold to the users as well as any time they get updated over-the-air (OTA).”

That’s fair, but who exactly is supposed to be doing these ongoing security reviews? Surely, Google isn’t suggesting that something so important should be left in the hands of OEMs unchecked. I conclude that Google will be adding extensive resources to its own security teams, to make sure that nothing such as this happens gets through the OEM checkpoints.

There is an issue of trusting Google — and Apple — when it comes to making sure that mobile operating systems and the associated apps are secure. OEMs have very little ROI to justify big security investments. The buck must top with Google. I don’t seem to recall BlackBerry having too many of these kinds of issues, and that was because, as a company, it prioritized security. (OK, perhaps it should have spared a bit of that priority for marketing, but I digress.)

If Google doesn’t do more for security, CIOs/CISOs/CSOs are going to either have to take on this task themselves — or seriously question which MOS they can justify supporting.



Source link

6 Ways to Check Which Versions of .NET Framework Are Installed

The Microsoft .NET Framework is an important feature of the modern Windows operating system. It provides developers with a ready-made collection of code that Microsoft maintains. Most of the time, you have no direct dealings with .NET Framework. However, that’s not always the case. At times, you need to know the specific version of the .NET Framework installed on your system.

Here are six ways you can find out which versions of .NET Framework are installed on your version of Windows.

Find Newer .NET Framework Versions: 4.5 and Later

There are three methods you can use to find out your .NET Framework version for versions 4.5 and later. “But Gavin,” I hear you say, “I’m doing this to find out which version I have, I don’t know if it is version 4.5 or not.”

You are exactly right. Checking for the .NET Framework version only takes a moment. You can quickly establish if you have .NET Framework version 4.5 or later. If you don’t, you can safely assume that you have an earlier version installed, or no .NET Framework version at all (which is highly unlikely).

1. Use the Registry Editor to Find the .NET Framework Version

regedit net framework dword value

You can find the .NET Framework versions installed on your system in the registry. (What is the Windows Registry, anyway?)

  1. Press Ctrl + R to open Run, then input regedit.
  2. When the Registry Editor opens, find the following entry:
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4
  3. Under v4, check for the Full If it is there, you have .NET Framework version 4.5 or later.
  4. In the right-hand panel, check for a DWORD entry named Release. If the Release DWORD exists, you have .NET Framework 4.5 or a later version.
  5. The Release DWORD data contains a value relating to the specific .NET Framework version. For instance, in the image below, the Release DWORD has a value of 461814. That means my system has .NET Framework 4.7.2 installed. Check the table below for your Release DWORD value.

.net frame work dword versions

You can cross-check the DWORD value against the value table below to find out the exact .NET Framework version on your system.

2. Use the Command Prompt to Find the .NET Framework Version

Type command into your Start Menu search bar, right-click the Best Match and select Run as Administrator.

Now, copy and paste the following command into the Command Prompt:

reg query "HKLMSOFTWAREMicrosoftNet Framework SetupNDPv4" /s

The command lists the installed .NET Frameworks for version 4. .NET Framework version 4 and later display as “v4.x.xxxxx.”

3. Use PowerShell to Find the .Net Framework Version

net framework powershell command

Type powershell into your Start Menu search bar, right-click the Best Match and select Run as Administrator.

Now, you can use the following command to check the value of the .NET Framework Release DWORD:

Get-ChildItem 'HKLM:SOFTWAREMicrosoftNET Framework SetupNDPv4Full' |  Get-ItemPropertyValue -Name Release | Foreach-Object { $_ -ge 394802 }

The command above returns True if the .NET Framework version is 4.6.2 or higher. Otherwise, it returns False. You can use the .NET Framework DWORD value table above to swap out the last six digits of the command for a different version. Check out my example:

The first command confirms that version 4.6.2 is present. The second confirms that version 4.7.2 is present. However, the third command checks for version 4.8, which I don’t have installed yet as the Windows 10 May Update hasn’t arrived on my system. Still, you get the gist of how the PowerShell command works with the DWORD value table.

Find an Older .NET Framework Version

regedit net framework older version

You can find out which old .NET Framework versions are installed on your system using the registry. The Registry Editor holds all the answers.

  1. Press Ctrl + R to open Run, then input regedit.
  2. When the Registry Editor opens, find the following entry:
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDP
  3. Check the NDP file in the registry for each .NET Framework version.

Check Your .NET Framework Version Using a Third-Party Tool

There are a couple of tools you can use to find the .NET Framework version on your system automatically. However, they’re not updated frequently, which is why knowing the manual method is handy, too.

1. Raymondcc .NET Detector

raymondcc net framework detector

The Raymondcc .NET Detector is one of the fastest and easiest detection tools to use. You download the folder, extract it, then run the executable. When the program runs, it shows a list of .NET Framework versions. The versions in black are installed on your system, while the gray versions are not. If you click on a grayed-out .NET Framework version, the program takes you to the installer.

Download: Raymondcc .NET Detector for Windows (Free)

The archive password is raymondcc

2. ASoft .NET Version Detector

asoft net framework version detectors

The ASoft .NET Version Detector works very similarly to the Raymondcc .NET Detector. Once you download and extract the program, run the executable. The program shows a list of currently installed .NET Framework versions. It also provides download links for those versions you do not have.

Download: ASoft .NET Version Detector for Windows (Free)

Simple Methods to Check Your .NET Framework Version

You now know several simple methods to check your .NET Framework version.

It isn’t always necessary to check your .NET Framework version. Many programs will check the version before installing and tell you if there is a program. Others will install the necessary version before commencing the installation, saving you the job of finding out the correct version and the hassle of downloading.

Still, it is always handy to know how to find the .NET Framework version manually. Want to find out more about the .NET Framework? Here’s why you need it and how you install it on Windows 10


Microsoft .NET Framework: Why You Need It and How to Install It on Windows




Microsoft .NET Framework: Why You Need It and How to Install It on Windows

You either need to install or update it. But do you know what the .NET Framework is? We show you why you need it and how you can get the latest version.
Read More

.

Explore more about: Computer Maintenance, Troubleshooting, Windows Update.



Source link