PSIRT openVuln API IOS-XE version invalid

[thiland]

On an ISR4321 device from the command line:

ISR4321# show version 
Cisco IOS XE Software, Version 03.16.02.S - Extended Support Release
Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S2, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Thu 11-Feb-16 08:58 by mcpre

However take a look at this string returned via SNMP from an ISR 4321:

Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S2, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2016 by Cisco Systems, Inc. Compiled Thu 11-Feb-16 08:58 by mcpre

ISR4k runs IOS-XE.  Does the API care which version I send it, 03.16.02.S or 15.5(3)S2?  Does it care about the format of the release version?

If I use the https://api.cisco.com/security/advisories/iosxe?version=15.5(3)S2 endpoint, it returns INVALID_IOSXE_VERSION.

If I use the https://api.cisco.com/security/advisories/iosxe?version=03.16.02.S endpoint, it returns INVALID_IOSXE_VERSION.

If I use the https://api.cisco.com/security/advisories/ios?version=03.16.02.S endpoint, it returns INVALID_IOS_VERSION.

If I use the https://api.cisco.com/security/advisories/ios?version=15.5(3)S2 endpoint, it returns correct results, but why?!

Enhancement requests:

• Combine both IOS and IOS-XE lookups into a single API endpoint.
• Allow for the submission of the IOS-XE version (3.16.02S) or the associated IOSd version (e.g., 15.5(3)S2), if not supported already

It's a big pain for me to determine if a code version is IOS or IOS-XE because Cisco is not consistent in finding this information via SNMP OIDs.

Just to determine if a device is IOS or IOS-XE I have to regex match if the System Description field contains "Denali", or "Everest", or "X86_64_LINUX_IOSD", etc. and it's going to be an ever-changing list.

Anyway, I'm stuck on a project now because I'm getting a lot of invalid version responses.  Any insight would be apprecaited!

[Omar Santos]

Hi Thiland,

I do not have control on the version inconsistency in the product show version and SNMP output. However, I can comment on the API ;-) Just for a reference only, the following whitepaper goes over numbering scheme. On the other hand, it looks like it you are already very familiar with the numbering scheme.

White Paper: Cisco IOS and NX-OS Software Reference Guide - Cisco

The 15.5(3)S2 is indeed the IOSd version and in the API it will work as you state above:

https://api.cisco.com/security/advisories/ios?version=15.5(3)S2

On the other hand, you have the correct syntax for the IOSXE version: https://api.cisco.com/security/advisories/iosxe?version=03.16.02.S

I have raised this with our the development team, as this may be a bug in the API. I will follow up with you shortly.

Thanks!

Omar

[thiland]

I definitely understand the SNMP output isn't under your control, but wanted to illustrate the (lack of) data I have to work and challenges it presents.

As far as I can tell there is no deterministic way to derive an IOS-XE version number from an IOSd version, or vice versa, nor an API endpoint to feed in an IOS-XE version and get the resulting IOSd version.

Taking into account the variation in version numbers (03.16.02.S, 15.5(3)S2, 16.4.2 (Denali), and having the API endpoints split between IOS and IOS-XE, it makes it near impossible for me to figure out which is the correct one to use.  Programmatically I'm going to have to send to both and see which one returns results which seems inefficient for both of us.

I understand that 15.5(3)S2 is the IOSd version, but in my opinion I should be able to get results using the IOS-XE endpoint. 

Thanks for looking into the possible bug.

-Tanner

[Omar Santos]

Hi Tanner,

I am still working with the dev team, but wanted to update you, since may may have found the problem.

I am able to get results for IOS-XE if I do not use the dot "." before the S (i.e., 3.16.2S). I am using the openVulnQuery phython client below, but it will be the same if you use any other client (or even curl for that matter). I will update you as soon as I get more information about this issue.

bash-3.2$ openVulnQuery --ios_xe 3\.16\.2S -f advisory_id sir first_fixed

[

    {

        "advisory_id": "cisco-sa-20170927-dhcp",

        "first_fixed": [

            "3.16.6S"

        ],

        "sir": "Critical"

    },

    {

        "advisory_id": "cisco-sa-20170927-ike",

        "first_fixed": [

            "3.16.6S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170927-pnp",

        "first_fixed": [

            "3.16.6S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170927-cc",

        "first_fixed": [

            "3.16.7S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170727-ospf",

        "first_fixed": [

            "3.16.6S"

        ],

        "sir": "Medium"

    },

    {

        "advisory_id": "cisco-sa-20170726-aniacp",

        "first_fixed": [

            ""

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170726-anidos",

        "first_fixed": [

            ""

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170726-anicrl",

        "first_fixed": [

            ""

        ],

        "sir": "Medium"

    },

    {

        "advisory_id": "cisco-sa-20170629-snmp",

        "first_fixed": [

            ""

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170322-l2tp",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170322-ztp",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170320-ani",

        "first_fixed": [

            ""

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20170320-aniipv6",

        "first_fixed": [

            "3.16.6S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20160928-aaados",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20160928-h323",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20160928-ios-ikev1",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20160928-msdp",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20160916-ikev1",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    },

    {

        "advisory_id": "cisco-sa-20160525-ipv6",

        "first_fixed": [

            "3.16.5S"

        ],

        "sir": "High"

    }

]