Impact
Customers that have a schema with a caveat using the in_cidr function, such as the following
caveat is_valid_ip(user_ip ipaddress, cidr string) {
user_ip.in_cidr(cidr)
}can get different results for two textual forms of the same IPv4 host. An allow-list (permit when in_cidr is true) fails closed for a mapped address; a deny-style check (negating in_cidr, or granting extra access for internal ranges) fails open.
In other words, the following .zed file fails the second assertion:
---
schema: |+
definition user {}
caveat is_valid_ip(user_ip ipaddress, cidr string) {
user_ip.in_cidr(cidr)
}
definition document {
relation viewer: user with is_valid_ip
permission view = viewer
}
relationships: >-
document:firstdoc#viewer@user:alice[is_valid_ip:{"cidr":"10.0.0.0/8"}]
assertions:
assertTrue:
- 'document:firstdoc#view@user:alice with {"user_ip": "10.1.2.3"}'
- 'document:firstdoc#view@user:alice with {"user_ip": "::ffff:a01:203"}'
Patches
v1.54.1
Workarounds
Do not use the in_cidr caveat function.
Impact
Customers that have a schema with a caveat using the
in_cidrfunction, such as the followingcan get different results for two textual forms of the same IPv4 host. An allow-list (permit when
in_cidris true) fails closed for a mapped address; a deny-style check (negatingin_cidr, or granting extra access for internal ranges) fails open.In other words, the following .zed file fails the second assertion:
Patches
v1.54.1
Workarounds
Do not use the
in_cidrcaveat function.