Coffeehouse Thread

12 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Another opinion poll.... Downlevel API's...

Back to Forum: Coffeehouse
  • User profile image
    pierlove

    Hi again, call me inquisitive today.

    I am curious to know what the general opinions out there are regarding the presence of various down-level API's on any particular client. For example the Framework v 1.1. Is that considered to be a vulnerability if it is present on a machine from some legacy app but no longer used? What if it is used by some old program?

    Also if you are on a present day machine what if any are the risks to the current OS by the presence of the older API?

    If the API isn't there an installation targeting 1.1 would alert the user to install said API.... but if it was "present" the app would "automatically" be supported based on "user execution". Is this correct?

    I am saying to myself as I write this that I should already know this... my gut is that the answer lies somewhere in the #GREY_FOGGY_AREA...

    James

  • User profile image
    JoshRoss

    As a general rule of thumb, the smaller the attack surface, the less vulnerable your machine and or enterprise is to attack.

    But, I am puzzled by your lack of question in your questions. If you don't need a windows component, don't install it. Recently, it seems that people don't have physical servers sitting around running a single lightweight app or nothing at all. But when they do, those scenarios are ideal candidates for virtualization.

    When your app has reached the end of its application life cycle, spin-down the VM and reclaim its bits. It's kind of like The Matrix, without the cool visuals or plot.

    -Josh

  • User profile image
    magicalclick

    @ObjectAntics: I didn't finish my security class. But, the basic is, have one machine with framework 1.1 and run your legacy app, but, only that app. Like above said, VM works will in here. Then you expose these as web service for other apps to gain access to the functionality. Even if it is vulnerable, there isn't anything useful to get on that machine, thus, making a shallow hole than a deep hole. Typically we separate our system into multiple wallets. So, if someone stole your of your wallet, your other wallet are still safe. Or just like how we spread out bets on gambling table or broaden stock investment. You can never stop all hackers. It WILL be hacked. You have to assume that already happened. And make sure the system as a whole, can stop the attacker getting more info before you realize and close the hole.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    pierlove

    So the question is to be clearer.... does the down-level API present risk?

    DNF as a whole is designed to be present Side=By-Side to allow for different age software to co-exist. So it's definitely an administrative decision.... shouldn't we be evolving towards a security model that goes back and picks up after itself?      MUCH OF IT IS REDUNDANT AND WASTE RIGHT?

    TIA

  • User profile image
    cheong

    .NET framework itself is no different than C++ runtime. It runs at the same level as your application.

    As long as you application don't listen to external port, the attack surface is not increased.

    If for some reason, you have to run something like 10+ years old FTP software, every security implications you can think of applies here.

    The following is specific to .NET v1.1, AFAIK, this installation itself does not contain parts the needs to listen to the network. So as long as you don't install/enable IIS on that machine, it shouldn't create more holes for bad guys to dig in. You could really just treat it as old C++ runtime.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    Sven Groot

    @cheong: That's a really narrow definition of attack surface. If you download a piece of malware that attempt to exploit some bug in .Net 1.1, it won't succeed if you don't have it.  So not having does reduce your attack surface, even though it's not listening for connections.

  • User profile image
    bondsbw

    @Sven Groot:  I guess that raises the question:  does .NET have access to any kernel calls or other privileged routines that are not afforded to other native apps?

    After all, if the answer is "no", then any .NET Framework bug that provides extra attack surface would actually be wrapping some underlying Windows bug.  Then just a bit of reverse engineering will provide an attacker with an exploit that does not require any .NET framework to be installed.

  • User profile image
    contextfree`

    In Windows store apps the .net framework is the only thing (besides Chakra) that can JIT, so it can be extra attack surface in that sense (although older versions of .net can't be used for apps anyway)

  • User profile image
    pierlove

    @Sven Groot: My point exactly. And the heart of the question..... When did we stop "UNISTALLING" the old versions of a system before moving to a new one?? Why are we supporting SIDE-BY-SIDE frameworks instead of making the NEWEST FRAMEWORK VERSION capable of doing only what it needs to do....and not allowing the legacy processes to execute without a specific "down-grade" approach.

    I think FORWARD is FORWARD and BACK is BACK... and that a single DEVICE isn't supposed to span TIME the way it does now.     Maybe I am over simplifying this, and perhaps I am losing my mind. Am I the only one that thinks this way? 

  • User profile image
    cheong

    @Sven Groot:.NET framework does not introduce new call to kernel. Even kernel functions are just wrapper to corresponding kernel API. Any checking done by kernel/virus scanners are NOT bypassed. If there are vulnueabilities at that level, you should worry about the system instead of a wrapper library.

    If I were virus writer, it'd be pretty weird choice to me to require .NET framework to call the functions instead of writing direct calls to the APIs.

    In other words, the attack surface is NOT enlarged by having .NET v1.1 runtime installed.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    cheong

    @ObjectAntics: Every new versions introduce a number of breaking changes. Most applications written for old runtime should be able to run in a newer version, but some may hit the unfortunate edge case and doomed if the old version of runtime is not there.

    Moreover, let's hope that you're not using 3rd-party libraries that locked-down the runtime version to use, then cease to exist so you won't be able to acquire newer version.

    This is part of what we called "DLL Hell", and side-by-side assemblies is designed to take care of that problem. .NET v4 runtime takes this to a new level by allowing process running different versions of .NET runtimes be loaded together. And that was previously impossible. 

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    pierlove

    @cheong: Interesting.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.