back to article Shared memory vulnerability in IBM's Db2 database could let nefarious insiders wreak havoc – so get patching

A bug-hunter has uncovered a vulnerability in IBM's popular enterprise database which, if left unpatched, could allow a local user to access data and kick off a denial-of-service attack. Security firm Trustwave said the shared memory vulnerability in Db2 - CVE-2020-4414 - was similar to the problems found with Cisco's Webex in …

  1. cschneid

    DB2 LUW, that is

    There are two flavors of DB2, the one that runs on IBM Z and the one that runs on Linux, Unix, and Windows (LUW). Last I knew, they did not share a code base, or shared very little. This affects the LUW version. In future I would suggest making that clear in the article. Perhaps even the headline.

    Yes, yes, I know IBM is a failure as a company because it's losing money (except for Z) and no one uses Z (except those who trumpet about their third 5-year plan to migrate to whatever is trendy these days) and so on and so forth ad infinitum ad nauseam etc. etc. etc.

    1. A.P. Veening Silver badge

      Re: DB2 LUW, that is

      Three flavors, DB2/400 is also still around.

  2. This post has been deleted by its author

    1. A.P. Veening Silver badge

      Re: I know this is a theoretical flaw but...

      Pretty common occurrence in SMB.

      1. SecretSonOfHG

        Re: I know this is a theoretical flaw but...

        There can't be that many DB2 instances running on SMB's. The support costs alone, not to mention the training and certification are high enough to put it out of reach of them.

        1. A.P. Veening Silver badge

          Re: I know this is a theoretical flaw but...

          Lots of SMB running on AS/400 (or iSeries or whatever name gives it this month) and those all run DB2/400 natively. Training and certification for those is most definitely affordable.

          1. TechHeadToo

            Re: I know this is a theoretical flaw but...

            Last I heard it was just i - like z, but i.

            And a nicer, better behaved DB I have yet to meet.

  3. Anonymous Coward
    Anonymous Coward

    Windows and mainframe apps

    I'm seing similar issues in reverse with an application hosted on Oracle / Unix where the devs are now really SQL Server/ Windows guys.

    SQL Server is the direction of travel for the vendor and the code base is developed there then ported to Oracle. The Dev's don't seem to know the basic Oracle tuning tweaks and each release now comes with free performance issues. I don't know if the app performs better on the windows platform or they just keep throwing more CPU's ate it but we are having to spend a lot of time running Oracle performance tools to then explain to the vendor what they need to do.

    We'll end up migrating to SQL: Server but Ironically we don't have the same level of expertise in SQL Server Performance management so we'll be stuck with whatever we get so if performance is dire and we need to throw additional cpu's at it our licencing SQL Server licencing costs will go up hugely. This could be the death knell of on-premises operation as going hosted would transfer that risk to the vendor.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021