There is a stack buffer overflow in MP4Box v1.0.1 at src/filters/dmx_nhml.c:1008 in the nhmldmx_send_sample() function szXmlFrom parameter which leads to a denial of service vulnerability.

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

- [x] I looked for a similar issue and couldn't find any.
- [x] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
- [x] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). 


Step to reproduce:

1.get latest commit code (GPAC version 1.1.0-DEV-rev1221-gd626acad8-master)
2.compile with --enable-sanitizer
3.run MP4Box -add poc.nhml -new new.mp4
Env:
Ubunut 20.04 , clang 12.0.1

ASAN report
```

=================================================================
==345223==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffde4ab80f8 at pc 0x000000491bf8 bp 0x7ffde4ab6bb0 sp 0x7ffde4ab6370
WRITE of size 5081 at 0x7ffde4ab80f8 thread T0
    #0 0x491bf7 in __interceptor_strcpy (/home/lly/pro/gpac_asan/bin/gcc/MP4Box+0x491bf7)
    #1 0x7f446088e9c5 in nhmldmx_send_sample /home/lly/pro/gpac_asan/src/filters/dmx_nhml.c:1008:45
    #2 0x7f446088e9c5 in nhmldmx_process /home/lly/pro/gpac_asan/src/filters/dmx_nhml.c:1341:7
    #3 0x7f44607bb997 in gf_filter_process_task /home/lly/pro/gpac_asan/src/filter_core/filter.c:2441:7
    #4 0x7f446079d965 in gf_fs_thread_proc /home/lly/pro/gpac_asan/src/filter_core/filter_session.c:1664:3
    #5 0x7f446079ce60 in gf_fs_run /home/lly/pro/gpac_asan/src/filter_core/filter_session.c:1901:2
    #6 0x7f44602be708 in gf_media_import /home/lly/pro/gpac_asan/src/media_tools/media_import.c:1486:2
    #7 0x526ea9 in import_file /home/lly/pro/gpac_asan/applications/mp4box/fileimport.c:1289:7
    #8 0x4eb996 in do_add_cat /home/lly/pro/gpac_asan/applications/mp4box/main.c:4257:10
    #9 0x4e7d46 in mp4boxMain /home/lly/pro/gpac_asan/applications/mp4box/main.c:5746:13
    #10 0x7f445f53f0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #11 0x429a4d in _start (/home/lly/pro/gpac_asan/bin/gcc/MP4Box+0x429a4d)

Address 0x7ffde4ab80f8 is located in stack of thread T0 at offset 5432 in frame
    #0 0x7f446088d93f in nhmldmx_process /home/lly/pro/gpac_asan/src/filters/dmx_nhml.c:1314
```

Different from issue 1911, the overflow memory is related to szXmlFrom parameter. The szXmlTo para has the same problem, please fix them together.

Buggy code at dmx_nhml.c:1008:
```
static GF_Err nhmldmx_send_sample(GF_Filter *filter, GF_NHMLDmxCtx *ctx)
{

	else if (!stricmp(att->name, "xmlFrom")) strcpy(szXmlFrom, att->value);
	else if (!stricmp(att->name, "xmlTo")) strcpy(szXmlTo, att->value);
}
```
[poc.zip](https://github.com/gpac/gpac/files/7123042/poc.zip)


Stack-buffer-overflow in MP4Box at src/filters/dmx_nhml.c:1008 in nhmldmx_send_sample
This is a GitHub Issue
repo:gpac
owner:gpac
Title : Stack-buffer-overflow in MP4Box at src/filters/dmx_nhml.c:1008 in nhmldmx_send_sample
Issue date:

--- start body ---

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

- [x] I looked for a similar issue and couldn't find any.
- [x] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
- [x] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). 


Step to reproduce:

1.get latest commit code (GPAC version 1.1.0-DEV-rev1221-gd626acad8-master)
2.compile with --enable-sanitizer
3.run MP4Box -add poc.nhml -new new.mp4
Env:
Ubunut 20.04 , clang 12.0.1

ASAN report
```

=================================================================
==345223==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffde4ab80f8 at pc 0x000000491bf8 bp 0x7ffde4ab6bb0 sp 0x7ffde4ab6370
WRITE of size 5081 at 0x7ffde4ab80f8 thread T0
    #0 0x491bf7 in __interceptor_strcpy (/home/lly/pro/gpac_asan/bin/gcc/MP4Box+0x491bf7)
    #1 0x7f446088e9c5 in nhmldmx_send_sample /home/lly/pro/gpac_asan/src/filters/dmx_nhml.c:1008:45
    #2 0x7f446088e9c5 in nhmldmx_process /home/lly/pro/gpac_asan/src/filters/dmx_nhml.c:1341:7
    #3 0x7f44607bb997 in gf_filter_process_task /home/lly/pro/gpac_asan/src/filter_core/filter.c:2441:7
    #4 0x7f446079d965 in gf_fs_thread_proc /home/lly/pro/gpac_asan/src/filter_core/filter_session.c:1664:3
    #5 0x7f446079ce60 in gf_fs_run /home/lly/pro/gpac_asan/src/filter_core/filter_session.c:1901:2
    #6 0x7f44602be708 in gf_media_import /home/lly/pro/gpac_asan/src/media_tools/media_import.c:1486:2
    #7 0x526ea9 in import_file /home/lly/pro/gpac_asan/applications/mp4box/fileimport.c:1289:7
    #8 0x4eb996 in do_add_cat /home/lly/pro/gpac_asan/applications/mp4box/main.c:4257:10
    #9 0x4e7d46 in mp4boxMain /home/lly/pro/gpac_asan/applications/mp4box/main.c:5746:13
    #10 0x7f445f53f0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #11 0x429a4d in _start (/home/lly/pro/gpac_asan/bin/gcc/MP4Box+0x429a4d)

Address 0x7ffde4ab80f8 is located in stack of thread T0 at offset 5432 in frame
    #0 0x7f446088d93f in nhmldmx_process /home/lly/pro/gpac_asan/src/filters/dmx_nhml.c:1314
```

Different from issue 1911, the overflow memory is related to szXmlFrom parameter. The szXmlTo para has the same problem, please fix them together.

Buggy code at dmx_nhml.c:1008:
```
static GF_Err nhmldmx_send_sample(GF_Filter *filter, GF_NHMLDmxCtx *ctx)
{

	else if (!stricmp(att->name, "xmlFrom")) strcpy(szXmlFrom, att->value);
	else if (!stricmp(att->name, "xmlTo")) strcpy(szXmlTo, att->value);
}
```
[poc.zip](https://github.com/gpac/gpac/files/7123042/poc.zip)


--- end body ---

A stack-buffer overflow vulnerability exists in the nhmldmx_send_sample function of GPAC's MP4Box, specifically at src/filters/dmx_nhml.c:1008. The vulnerability arises from the use of the strcpy function without proper bounds checking, allowing an attacker to write beyond the allocated stack buffer. This can lead to potential exploitation, including arbitrary code execution or denial of service.