* malicious devices causing unaligned accesses [v2]
@ 2022-02-17 8:46 Oliver Neukum
2022-02-17 10:27 ` Bjørn Mork
0 siblings, 1 reply; 3+ messages in thread
From: Oliver Neukum @ 2022-02-17 8:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stern, USB list, netdev, Giuliano Belinassi, Bjørn Mork
Hi,
going through the USB network drivers looking for ways
a malicious device could do us harm I found drivers taking
the alignment coming from the device for granted.
An example can be seen in qmi_wwan:
while (offset + qmimux_hdr_sz < skb->len) {
hdr = (struct qmimux_hdr*)(skb->data + offset);
len = be16_to_cpu(hdr->pkt_len);
As you can see the driver accesses stuff coming from the device with the
expectation
that it keep to natural alignment. On some architectures that is a way a
device could use to do bad things to a host. What is to be done about
that?
Regards
Oliver
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: malicious devices causing unaligned accesses [v2]
2022-02-17 8:46 malicious devices causing unaligned accesses [v2] Oliver Neukum
@ 2022-02-17 10:27 ` Bjørn Mork
2022-02-17 10:35 ` Oliver Neukum
0 siblings, 1 reply; 3+ messages in thread
From: Bjørn Mork @ 2022-02-17 10:27 UTC (permalink / raw)
To: Oliver Neukum
Cc: Greg Kroah-Hartman, stern, USB list, netdev, Giuliano Belinassi
Oliver Neukum <oneukum@suse.com> writes:
> Hi,
>
> going through the USB network drivers looking for ways
> a malicious device could do us harm I found drivers taking
> the alignment coming from the device for granted.
>
> An example can be seen in qmi_wwan:
>
> while (offset + qmimux_hdr_sz < skb->len) {
> hdr = (struct qmimux_hdr*)(skb->data + offset);
> len = be16_to_cpu(hdr->pkt_len);
>
> As you can see the driver accesses stuff coming from the device with the
> expectation
> that it keep to natural alignment. On some architectures that is a way a
> device could use to do bad things to a host. What is to be done about
> that?
We can deal with this the same way we deal with hostile hot-plugged CPUs
or memory modules.
Yes, the aligment should probably be verified. But there are so many
ways a hostile network adapter can mess with us than I don't buy the
"malicious device" argument...
FWIW, the more recent rmnet demuxing implementation from Qualcomm seems
to suffer from the same problem.
struct sk_buff *rmnet_map_deaggregate(struct sk_buff *skb,
struct rmnet_port *port)
{
struct rmnet_map_header *maph;
struct sk_buff *skbn;
u32 packet_len;
if (skb->len == 0)
return NULL;
maph = (struct rmnet_map_header *)skb->data;
packet_len = ntohs(maph->pkt_len) + sizeof(struct rmnet_map_header);
(this implementation moves skb->data by packet_len instead of doing the
offset calculation, but I don't think that makes any difference?)
I guess there is no alignment guarantee here, whether the device is
malicious or not. So we probably have to deal with unaligned accesses to
maph/hdr->pkt_len?
Bjørn
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: malicious devices causing unaligned accesses [v2]
2022-02-17 10:27 ` Bjørn Mork
@ 2022-02-17 10:35 ` Oliver Neukum
0 siblings, 0 replies; 3+ messages in thread
From: Oliver Neukum @ 2022-02-17 10:35 UTC (permalink / raw)
To: Bjørn Mork, Oliver Neukum
Cc: Greg Kroah-Hartman, stern, USB list, netdev, Giuliano Belinassi
On 17.02.22 11:27, Bjørn Mork wrote:
> Oliver Neukum <oneukum@suse.com> writes:
>
>> Hi,
>>
>> going through the USB network drivers looking for ways
>> a malicious device could do us harm I found drivers taking
>> the alignment coming from the device for granted.
>>
>> An example can be seen in qmi_wwan:
>>
>> while (offset + qmimux_hdr_sz < skb->len) {
>> hdr = (struct qmimux_hdr*)(skb->data + offset);
>> len = be16_to_cpu(hdr->pkt_len);
>>
>> As you can see the driver accesses stuff coming from the device with the
>> expectation
>> that it keep to natural alignment. On some architectures that is a way a
>> device could use to do bad things to a host. What is to be done about
>> that?
> We can deal with this the same way we deal with hostile hot-plugged CPUs
> or memory modules.
Yes. That is a basic decision that needs to be made
> Yes, the aligment should probably be verified. But there are so many
> ways a hostile network adapter can mess with us than I don't buy the
> "malicious device" argument...
Sure, so what is the level of damage that is acceptable?
>
> FWIW, the more recent rmnet demuxing implementation from Qualcomm seems
> to suffer from the same problem.
>
>
> struct sk_buff *rmnet_map_deaggregate(struct sk_buff *skb,
> struct rmnet_port *port)
> {
> struct rmnet_map_header *maph;
> struct sk_buff *skbn;
> u32 packet_len;
>
> if (skb->len == 0)
> return NULL;
>
> maph = (struct rmnet_map_header *)skb->data;
> packet_len = ntohs(maph->pkt_len) + sizeof(struct rmnet_map_header);
>
>
> (this implementation moves skb->data by packet_len instead of doing the
> offset calculation, but I don't think that makes any difference?)
>
> I guess there is no alignment guarantee here, whether the device is
> malicious or not. So we probably have to deal with unaligned accesses to
> maph/hdr->pkt_len?
Yes, as far as I can tell a device is fully in spec if it sends frames as
tightly packed as possible, so this is simply a bug, not a security issue.
Regards
Oliver
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-02-17 10:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-17 8:46 malicious devices causing unaligned accesses [v2] Oliver Neukum
2022-02-17 10:27 ` Bjørn Mork
2022-02-17 10:35 ` Oliver Neukum
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).