Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supernode crash when creating dynamic keys for username-password auth #30

Closed
aarojun opened this issue May 14, 2024 · 4 comments
Closed
Assignees

Comments

@aarojun
Copy link

aarojun commented May 14, 2024

Hey,
This is a repeat of the following issue: ntop/n2n#1161
Testing on a Windows 11 machine this happens on both n3n 3.3.4 and n2n 3.1.1 binaries with minimal config settings.

If username/password auth is enabled and community.list has any users listed the supernode process closes after announcing it is calculating dynamic keys.
e.g. the following is ran and the program closes with no error code.

n3n-supernode.exe start dynkey_test
14/May/2024 11:13:11 [src/sn_utils.c:433] added allowed community 'N3Ngroup' [total: 1]
14/May/2024 11:13:11 [src/sn_utils.c:1430] assigned sub-network 10.114.25.0/24 to community 'N3Ngroup'
14/May/2024 11:13:11 [src/sn_utils.c:378] added user 'Tester' with public key 'Sb7i-eKf3csny8Ai3aQGq+piopwrxBH-iUFzAONioWy' to community 'N3Ngroup'
14/May/2024 11:13:11 [src/sn_utils.c:479] loaded 1 fixed-name communities from community.list
14/May/2024 11:13:11 [src/sn_utils.c:482] loaded 0 regular expressions for community name matching from community.list
14/May/2024 11:13:11 [src/sn_utils.c:147] started shared secrets calculation for edge authentication
14/May/2024 11:13:11 [src/sn_utils.c:163] calculated shared secrets for edge authentication
14/May/2024 11:13:11 [src/sn_utils.c:172] calculating dynamic keys

community.list

N3Ngroup
* Tester Sb7i-eKf3csny8Ai3aQGq+piopwrxBH-iUFzAONioWy

dynkey_test.conf

[community]
key=EncryKey
cipher=ChaCha20

[connection]
bind=6777

[logging]
verbose=4

[supernode]
community_file=community.list
federation=N3Nfed

auto_ip_max=10.114.26.0/24
auto_ip_min=10.114.25.0/24
@hamishcoleman hamishcoleman self-assigned this May 14, 2024
@aarojun
Copy link
Author

aarojun commented May 14, 2024

For more context: Windows Event Viewer reports this Error as exception code 0xc0000374 (Heap Corruption) for module ntdll.dll

Faulting application name: n3n-supernode.exe, version: 0.0.0.0, time stamp: 0x663c8682
Faulting module name: ntdll.dll, version: 10.0.22621.3374, time stamp: 0xeae8eecc
Exception code: 0xc0000374
Fault offset: 0x000000000010c169

Watching ProcessMonitor this appears to happen soon after the supernode closes the community.list file.

Using WinDbg and running !analyze -v on crash .dmp file:

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Check Image - Checksum mismatch - Dump: 0x21eed5, File: 0x21b96e - C:\ProgramData\Dbg\sym\ntdll.dll\EAE8EECC216000\ntdll.dll

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 453

    Key  : Analysis.Elapsed.mSec
    Value: 13464

    Key  : Analysis.IO.Other.Mb
    Value: 15

    Key  : Analysis.IO.Read.Mb
    Value: 2

    Key  : Analysis.IO.Write.Mb
    Value: 18

    Key  : Analysis.Init.CPU.mSec
    Value: 46

    Key  : Analysis.Init.Elapsed.mSec
    Value: 16271

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 81

    Key  : Failure.Bucket
    Value: HEAP_CORRUPTION_ACTIONABLE_BlockNotBusy_DOUBLE_FREE_c0000374_ntdll.dll!RtlpFreeHeapInternal

    Key  : Failure.Hash
    Value: {f9e860eb-b03f-7415-804c-7e671e26c730}

    Key  : Timeline.OS.Boot.DeltaSec
    Value: 3600

    Key  : Timeline.Process.Start.DeltaSec
    Value: 2

    Key  : WER.OS.Branch
    Value: ni_release

    Key  : WER.OS.Version
    Value: 10.0.22621.1


FILE_IN_CAB:  n3n-supernode.exe.20332.dmp

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

CONTEXT:  (.ecxr)
rax=000000000000c000 rbx=00000000c0000374 rcx=000002a3f9210001
rdx=000002a3f9210c38 rsi=0000000000000001 rdi=00007ffdd97328b0
rip=00007ffdd96bc169 rsp=000000b2f21fe320 rbp=000002a3f9315c00
 r8=000002a3f9210c38  r9=0000000000000000 r10=000002a3f92104f8
r11=0000000000000000 r12=0000000000000000 r13=000002a3f9310000
r14=000002a3f93117e8 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!RtlReportFatalFailure+0x9:
00007ffd`d96bc169 eb00            jmp     ntdll!RtlReportFatalFailure+0xb (00007ffd`d96bc16b)
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ffdd96bc169 (ntdll!RtlReportFatalFailure+0x0000000000000009)
   ExceptionCode: c0000374
  ExceptionFlags: 00000081
NumberParameters: 1
   Parameter[0]: 00007ffdd97328b0

PROCESS_NAME:  n3n-supernode.exe

ERROR_CODE: (NTSTATUS) 0xc0000374 - A heap has been corrupted.

EXCEPTION_CODE_STR:  c0000374

EXCEPTION_PARAMETER1:  00007ffdd97328b0

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Heap_Error_Type] from Frame:[0] on thread:[PSEUDO_THREAD] ; Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

FAULTING_THREAD:  ffffffff

STACK_TEXT:  
00000000`00000000 00000000`00000000 ntdll!RtlpFreeHeapInternal+0x0


STACK_COMMAND:  !heap ; ** Pseudo Context ** ManagedPseudo ** Value: ffffffff ** ; kb

SYMBOL_NAME:  ntdll!RtlpFreeHeapInternal+0

MODULE_NAME: ntdll

IMAGE_NAME:  ntdll.dll

FAILURE_BUCKET_ID:  HEAP_CORRUPTION_ACTIONABLE_BlockNotBusy_DOUBLE_FREE_c0000374_ntdll.dll!RtlpFreeHeapInternal

OS_VERSION:  10.0.22621.1

BUILDLAB_STR:  ni_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  10.0.22621.3374

FAILURE_ID_HASH:  {f9e860eb-b03f-7415-804c-7e671e26c730}

Followup:     MachineOwner
---------

hamishcoleman added a commit to hamishcoleman/n3n that referenced this issue May 15, 2024
The speck_init() function will always allocate its own buffer, so dont
allocate one as that leads to memory leaks.

In some configuations, the speck_init will not use the standard malloc()
and this may cause issues when trying to use free() on the returned ctx.

This issue definitely occurs with the Windows builds and lead to the
supernode aborting with "exception code 0xc0000374 (Heap Corruption)"

(Ref n42n#30)
@hamishcoleman
Copy link
Contributor

Thank you for your clear and concise reproduction steps - that was very helpful.

I believe I have addressed this bug in 51eb3d7 - are you able to test the windows binaries from https://github.com/hamishcoleman/n3n/actions/runs/9088706213/artifacts/1503386924 ?

@aarojun
Copy link
Author

aarojun commented May 15, 2024

Thank you! The issue is fixed with these binaries and I was able to get a supernode running with successful edge connections.

@aarojun aarojun closed this as completed May 15, 2024
@hamishcoleman
Copy link
Contributor

Great to hear. Thanks for confirming that.

I will make a new bugfix release with this change shortly.

hamishcoleman added a commit to hamishcoleman/n3n that referenced this issue May 18, 2024
The speck_init() function will always allocate its own buffer, so dont
allocate one as that leads to memory leaks.

In some configuations, the speck_init will not use the standard malloc()
and this may cause issues when trying to use free() on the returned ctx.

This issue definitely occurs with the Windows builds and lead to the
supernode aborting with "exception code 0xc0000374 (Heap Corruption)"

(Ref n42n#30)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants